Same problem on my installation... The drupal piwik module is broken because of this problem https://www.drupal.org/node/2483815

Yes, since Piwik 2.13.0 we do return a HTTP 400 (Bad request) when requesting piwik.php without any parameters since it cannot track anything without any parameters. We missed to document/announce that, I'm very sorry about that. I will add this now.

Can you use eg piwik.php?rec=0 instead?

I'm wondering for what kind of checks you use piwik.php?

Is this maybe also related to #7810 (Stable page for ELB health check)?

Thanks for your reply. Unfortunately that doesn't solve the problem for me. Still receiving 400 code with parameters.

True, this morning I got a 200 when I tried it but now getting a 400. Weird... What exactly do you want to monitor / check by calling piwik.php? Is it a requirement that it is the piwik.php? or could it just be any file?

I think it could be any file. We're just monitoring the return code with a monitoring system and since it worked all the time there was no need to change it. Is there another way to verify that the piwik installation is working?

@mattab what do we test for in our monitoring? I think we do test for something?

Also you might be interested in #7810 as well

Well the old behaviour was okay for us, I don't see the point in changing the default return code to 400 for the piwik.php.

To test the application it must be accessible via http and the application must be able to establish a database connection (and maybe even run a query on the database). The processes for web- and database-server are monitored separately.

and the application must be able to establish a database connection (and maybe even run a query on the database)

Just FYI: I don't think piwik.php does this when there are no URL parameters but I'm not 100% sure. As another user asked for it in the other issue maybe it actually makes sense to provide an "API" / file for this that tests different kind of things. index.php cannot be really used since it might redirect when there is an update to execute. Waiting for feedback of @mattab for now

Users need to enter the url to their piwik installation in Drupal. The only way to verify that they entered the correct url to piwik is doing a http request to piwik and verify that the tracker path is correct. Therefore I have chosen piwik.php with status code 200 in past. Blocking request to this php file with status 400 is bad idea as this has broken now ~17.000 installations.

I can change this in a future release, but now all current installations are broken and to whatever I'm changing it now, you may break it again.

OK, what I will do for now is to return a HTTP 200 in case a GET piwik.php is performed without any query or POST parameters. EG GET http://example.org/piwik.php will return a HTTP 200. Is that okay?

Next step would be at some point to actually provide a file or API for this maybe. Waiting for response of @mattab re my previous question.

I reckon we can close this issue as soon as the PR is merged and discuss everything following in #7810

The drupal module only makes a GET - no POST. Solution sounds fine. Thanks.

Looking forward to a reliable and future safe solution.

Aside - how soon can we expect a release with this fix included? And how about adding a comment to the code to explain the reason so it does not break again?

I added a test and explained it there to make sure it won't be removed again and explained it there.

I'm not sure how soon we can expect it. Usually we release a new version around the 15th of a month. Possibly this will be the case. @mattab can tell more re this.

Just FYI: I don't think piwik.php does this when there are no URL parameters but I'm not 100% sure. As another user asked for it in the other issue maybe it actually makes sense to provide an "API" / file for this that tests different kind of things. index.php cannot be really used since it might redirect when there is an update to execute. Waiting for feedback of @mattab for now

Created an issue to discuss How do I monitor that Piwik service is up? #7904

Why not reuse #7810 ? Or is that something different?

Hello, why is a HEAD-request not allowed?

what do you mean by it's not allowed? I haven't tested it but should work in general?

OK, what I will do for now is to return a HTTP 200 in case a GET piwik.php is performed without any query or POST parameters. EG GET http://example.org/piwik.php will return a HTTP 200. Is that okay?

So, you have only allowed a GET without any parameters but not a HEAD.

Examples:

telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /piwik.php
Piwik is a free/libre web analytics that lets you keep control of your data.Connection closed by foreign host.

telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
HEAD /piwik.php

<title>400 Bad Request</title>

Bad Request

Your browser sent a request that this server could not understand.

Connection closed by foreign host.

OK I get it. The code checks for GET specifically. Do you mind creating a new issue for this as this one is already resolved and the HEAD request is a different feature/bug? We should maybe always allow HEAD and GET interchangably

Just to let you know the issue is still there with the upgrade to 2.14.1 and is related to database.
The real issue I get is:
Error query: fetch() failed: Unknown column 'visit_first_action_time' in 'field list' : ...
but the error is masked with http error code 400.
So or the update didn't update the database schema or there's a typo in the field name in the code .

A new issue for HEAD-requests and the http-response-code 400 was created: #8397

With Piwik 2.14.2, using the proxy-script, I saw a lot of "400 Bad Request" today. Which is the second time after 2015-07-14.

The request URLs look legit. First I thought it might be a problem with the database because it had connection problems around the same time but when I rerequest one of the URLs now I still get the error without db connection issues.

Can there be another reason besides missing parameters?

It can have many different reasons. For example if the requested website can't be found (should not be the case here) or if for any other reason there are no logged requests. I'd recommend to create a new issue or to ask in forum