Closed bclozel closed 4 years ago
The RFC states that some servers might reject a GET with a body but that it otherwise has no defined semantics. Does the body have contents of 0\r\n
?
I guess you're right. The RFC states that:
The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. Request message framing is independent of method semantics, even if the method does not define any use for a message body.
So in that case, I guess the client should at least send a 0\r\n
body to send an empty body if nothing has been sent.
Right now the client sends the following:
GET /greeting HTTP/1.1\r\n
transfer-encoding: chunked\r\n
host: localhost:50419\r\n
\r\n
0\r\n
\r\n
Is there something wrong with this request?
Doesn't look like it, no. We can potentially update MWS to correctly ignore bodies on non-body HTTP methods, but we'll have to look more closely at the RFC to see if there are specific HTTP methods where the body is completely forbidden before doing so.
The spec is actually quite liberal. GET requests may have bodies but they can be ignored by the server. AFAIK, the only request method that forbids request bodies is HEAD.
I have the same problem. Would it be a solution to make it configurable?
Won't fix. We reject for clients because we are opionated, doing the same here.
I'm using an HTTP client that sends a
"Transfer-Encoding: chunked"
HTTP request header for all requests, including with empty bodies. When testing that client withMockWebServer
, I'm getting the following:Why is this enforced? Is there a strong reason or something in the HTTP spec that qualifies those requests as invalid? Could we relax that check if not necessary?