Requiring correct http methods on AdminController
#7806
Conversation
521a363 to
70ec961
Compare
|
@mamazu do we need to keep |
|
I don't think the controller could handle them. |
|
@mamazu nothing about the handling its more about HEAD, OPTION request should behave the same like currently, they should not return a 406 or other error code. Not sure if GET includes HEAD and OPTION requests. |
|
@alexander-schranz I just checked it out, the |
|
Did some research. The option request should just return the header "Allow: OPTIONS, GET, ..." which this controller doesn't do. So sending an option request to this endpoint would be nonsense anyways. |
|
As said its not about handling options request. More how this change could effect existing applications who maybe doing HEAD or OPTIONS request to our APIs. |
|
Added |
| if ($request->getMethod() == Request::METHOD_OPTIONS) { | ||
| $response = new Response(); | ||
| $response->headers->set('Allow', 'GET, OPTIONS, HEAD'); | ||
| return $response; | ||
| } |
There was a problem hiding this comment.
| if ($request->getMethod() == Request::METHOD_OPTIONS) { | |
| $response = new Response(); | |
| $response->headers->set('Allow', 'GET, OPTIONS, HEAD'); | |
| return $response; | |
| } |
Would not answer options request currently think that would be better handled in own bundle, via request listener.
|
Oops, that was code where I was just playing around. Removed it. |
51da4f9 to
2520a25
Compare
What's in this PR?
The
metadataand thetranslationsendpoints never accept any data so calling them with anything other than a get would not make sense. Let's also enforce that.Why?
This makes it clear to the caller of the API that this endpoint only returns data.
In the long run those should be moved to their own controller classes.