New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: HTTP server should respond with 100 Continue for zero-length "Expect: 100-continue" requests #16799
Comments
Wow, that's a bizarre edge case. But the RFC you cite is deprecated. The replacement seems like it's clarified the rules here: https://tools.ietf.org/html/rfc7231#section-5.1.1
On a first skim, I'm not seeing the requirement in RFC 7231. A client sending 100-continue for a 0-lengthed body is dumb, too. The documented intent of 100-continue is for clients who are sending large bodies. I'm not sure this is worth fixing, or that Go is even out of compliance. Do you see otherwise in RFC 7231? |
RFC 7230 does seem to make a distinction between a zero-length body and no body:
By that, if a request explicitly has a That's being pedantic, but I think it's the right interpretation. I do agree with you that the client code is being dumb in either case, but I need to work with that dumb client code, and the http package does not provide any mechanism for changing this behavior from outside. The fix is to remove the second condition from this if-statement. It shouldn't impact existing servers. If you agree that it's a small enough change and worthwhile, I'll submit a patch. |
Ignoring the RFC pedantry for a second, I don't even think that's enough of a fix. Consider how Go's 100-continue actually works: we don't send 100-continue to the peer unless/until the ServeHTTP handler does a Read from the Request.Body. But if the request body is 0 bytes, it's very likely that either/both: a) the user will look at Request.ContentLength == 0 and never do a Read at all, Most likely (a), though. If this is important, you'd want to send the 100-continue to the peer unconditional on whether the ServeHTTP handler ever looks at RequestBody. So the fix is a little bit more involved. But writing a test is usually 10-50x more code than the fix itself, and a test is required for all HTTP changes too, otherwise it would just regress, and then there's no point fixing it in the first place. (Sorry, little digression, knee-jerking at the description of the fix as a "trivial (one-line) patch" from the email thread about this, since it's always more than 1 line) Anyway, if you want to send that in, feel free. |
Paging @mnot for HTTP pedantry. Mark, if an HTTP client sends "Expect: 100-continue" and also "Content-Length: 0", what should (or MUST NOT) a server do? |
That includes a zero-length body when the client has said it's sending zero bytes. |
Sounds alright by me then. Still, I would like it if server handlers had more control over expectations. I'll play around with the code a bit and see if I can come up with something nice that won't break anything. |
@bradfitz, based on mnot's response, it sounds like the server is already behaving properly. Can we close this? |
go version
)?go1.6.3 linux/amd64
go env
)?GOARCH="amd64"
GOOS="linux"
Make an HTTP request with the headers
Expect: 100-continue
andContent-Length: 0
to anhttp.Server
. The server handler reads the (zero-length) response body and responds with a success status.A
100 Continue
response on the wire, followed by a200 OK
.Only a
200 OK
response.RFC 2616 says the following:
The last sentence implies that, when an
Expect: 100-continue
request header is present and the request was successfully handled by the server, it's incorrect behavior for the server to send a200 OK
without a preceding100 Continue
.http.Server
does not exhibit the correct behavior with zero-length requests.The text was updated successfully, but these errors were encountered: