You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A server may set an empty Content-type header on request types with no body, e.g. GET (this happens with default fastcgi_params in Nginx). When this occurs, the request will fail and return a 415 since no parser is available for empty content. There should be some guardrails in place to ensure that when a request doesn't (or shouldn't) have a body, we don't try and fail to parse it and subsequently reject an acceptable request.
There's a plethora of ways to approach this. An allow list of request methods seems like a bad choice in case some weird esoteric type comes up. A block list may work. Using the body size (either by the content-length header or strlen) should be safe. It may be enough to simply handle an empty header and treat it as equivalent to not set.
The text was updated successfully, but these errors were encountered:
Related to guzzle/psr7#363:
A server may set an empty
Content-type
header on request types with no body, e.g.GET
(this happens with defaultfastcgi_params
in Nginx). When this occurs, the request will fail and return a415
since no parser is available for empty content. There should be some guardrails in place to ensure that when a request doesn't (or shouldn't) have a body, we don't try and fail to parse it and subsequently reject an acceptable request.There's a plethora of ways to approach this. An allow list of request methods seems like a bad choice in case some weird esoteric type comes up. A block list may work. Using the body size (either by the content-length header or strlen) should be safe. It may be enough to simply handle an empty header and treat it as equivalent to not set.
The text was updated successfully, but these errors were encountered: