Opened 10 years ago
Last modified 6 years ago
#32126 new defect (bug)
XML-RPC stopped working with 4.2 in a cross-domain scenario
Reported by: | flymike | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.2 |
Component: | XML-RPC | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
Bug fix #20986 in wp-includes/class-IXR.php unconditionally returns status 405 to all request methods except POST. Additionally, an invalid Allow: header is returned.
But OPTIONS is a perfectly valid preflight request sent by XML-RPC clients, especially in a cross-domain scenario, to determine if a subsequent request (like POST) will be allowed - or if a cross-domain request will be allowed.
Unconditionally returning 405 prevents those clients from subsequently sending their POST request. This broke my XML-RPC client, which previously worked in 4.1.3.
Proposed fix: respond correctly to an OPTIONS request, by examining (any) Access-Control-Request-Methods: header for PUT, and returning an Access-Control-Allowed-Methods: header containing PUT with status 200.
Request for enhancement: fully support CORS by adding an admin dialog which defines what hosts (or none, or all) will be accepted for cross-domain requests, and return the appropriate Access-Control-Allow-Origin: header.
Change History (3)
#3
in reply to:
↑ 1
@
9 years ago
Replying to markoheijnen:
Maybe
Allow
should have beenAccess-Control-Allow-Methods
.
Allow: POST
is the correct header to return with a 405
in this case.
The XML-RPC API has no CORS support, and I'd be surprised if cross-site requests from a modern browser worked before the quoted change in r31004, as the OPTIONS request would've lacked the required CORS headers.
Allow
should have beenAccess-Control-Allow-Methods
. Doing an admin dialog would be a no go.