xmlrpc.php should return http 405 for get requests (and not 200)

[rhertzog]

$ curl -v http://raphaelhertzog.com/xmlrpc.php
[...]
> GET /xmlrpc.php HTTP/1.1
 
< HTTP/1.1 200 OK
[...]
XML-RPC server accepts POST requests only.

The error returned should be reflected in the HTTP return code: it should return HTTP 405 (Method not allowed) instead of 200 (OK).

This has been originally reported in the Debian bug tracking system: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598124

[maxcutler]

Added a patch for this. Not sure if this should go in 3.4.x or 3.5, need core dev input.

[josephscott]

Returning 405 sounds reasonable.

@maxcutler - I don't think we should hard code HTTP 1.1 as the response. Will HTTP 1.0 clients freak out if we do that?

[maxcutler]

Replying to josephscott:

@maxcutler - I don't think we should hard code HTTP 1.1 as the response. Will HTTP 1.0 clients freak out if we do that?

Valid question. I was just following examples of similar behavior elsewhere in core.

• /wp-comments-post.php@L10
• /wp-includes/class-wp-atom-server.php (multiple)

Maybe there should be a core API for this that is smarter, like found in load.php@L163-168?

[nacin]

Maybe there should be a core API for this that is smarter, like found in load.php@L163-168?

We have one — status_header( 405 ); The logic in load.php is simply there because under maintenance mode, we have very little of WordPress loaded.

[maxcutler]

Thanks nacin and sivel. Uploaded a new patch that uses status_header.

[nacin]

Oops, time to commit this. :)

[nacin]

In 31004:

XML-RPC: Send 405 Method Not Allowed for GET requests.

props maxcutler.
fixes #20986.

[nacin]

I wonder if this will break clients that check for a 200 from GET /xmlrpc.php to see if that URL is accessible. I guess we will find out.

[marcmoore]

"I wonder if this will break clients that check for a 200 from GET /xmlrpc.php to see if that URL is accessible. I guess we will find out."

It did - SiteImprove now reports 405 errors for every page in my web site, pretty much negating the value of its report. Sure, you can say that SiteImprove is at fault, yada yada, but this change isn't helping me.

[cchen]

This change also disabled the mimic.js, the Xml Rpc Request.send function won't work