![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 11 years ago
Last modified 7 years ago
#32126 new defect (bug)
XML-RPC stopped working with 4.2 in a cross-domain scenario
| Reported by: | flymike | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | XML-RPC | Version: | 4.2 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
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
@
11 years ago
Replying to markoheijnen:
Maybe
Allowshould 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.
Maybe
Allowshould have beenAccess-Control-Allow-Methods. Doing an admin dialog would be a no go. Most users would not understand that part.