Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: HTTP server should respond with 100 Continue for zero-length "Expect: 100-continue" requests #16799
RFC 2616 says the following:
The last sentence implies that, when an
Wow, that's a bizarre edge case.
But the RFC you cite is deprecated. The replacement seems like it's clarified the rules here:
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.
That includes a zero-length body when the client has said it's sending zero bytes.