Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#35975 closed defect (bug) (fixed)

OPTIONS request to REST API does not return correct Accept header

Reported by: joehoyle's profile joehoyle Owned by: joehoyle's profile joehoyle
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.4
Component: REST API Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

The REST API should (and usually does) send an Accept header along with requests to tell the client what over HTTP verbs can be sent. This is determined by 1: the endpoint registration for those methods, and 2: by running the permission_callback on the endpoint to see if the request could run the request.

In the event of an OPTIONS request, which is the typical use case for wanting to see what requests can be accepted, we are not running the permission_callback on the endpoints, which means the Accept is not true.

This is a bug, caused by the shortcircuited routing in the OPTIONS request handling, specifically the matched_route is not set on the Response object, so the Accept handler can not determine what permission checks to run.

Attachments (2)

35975.diff (509 bytes) - added by joehoyle 9 years ago.
35975.2.diff (1.7 KB) - added by joehoyle 9 years ago.

Download all attachments as: .zip

Change History (7)

@joehoyle
9 years ago

#1 @joehoyle
9 years ago

  • Keywords has-patch needs-unit-tests added

This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.


9 years ago

@joehoyle
9 years ago

#4 @joehoyle
9 years ago

  • Keywords has-unit-tests added; needs-unit-tests removed

@rmccue I've removed the Accept header handling entirely from the OPTIONS request handler, and instead let that be ticket up by the function rest_send_allow_header. Also added unit tests for this.

Good news is we were only sending Accept (when we meant Allow) on OPTIONS responses, which were also not checking permissions checks. This means if someone was relying on Accept (when then actually wanted allow), the value they were relying on was likely incorrect too.

#5 @joehoyle
9 years ago

  • Owner set to joehoyle
  • Resolution set to fixed
  • Status changed from new to closed

In 36829:

OPTIONS requests to REST API should return Allow header.

An OPTIONS request was incorrectly returning an "Accept" header which
was a typo of "Allow". This meant Accept was showing "GET, POST" for example,
however it was also not running the permission checks on the endpoints.

Instead, the correct route needs to be set on the request object, which means
the normal handling for the Allow header will kick in. This technically
breaks backwards compatibility, however given the value of Accept was also wrong
then this should not be an issue.

Fixes #35975.

Note: See TracTickets for help on using tickets.