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 | Owned by: | 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.
@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.