-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: Client support for Expect: 100-continue #3665
Comments
See also issue #2184, different but related. |
Adding the "Suggested" label, if somebody wants to take this on. I expect it to be somewhat involved, though. It should probably be opt-in: users will need to add "Expect": "100-continue" to their request before sending it. And then in transport.go, when we're going to write the request, write and flush the headers, create a channel, and then wait on the channel response and a 1 second timer (like curl). If after 1 second no response, send the body anyway. If the channel gives you a non-100 HTTP response, use that. If the channel gives a 100, start writing the body. Labels changed: added suggested, size-l. |
Sent out https://golang.org/cl/8166045 |
This issue was updated by revision a79df7b. R=golang-dev, dsymonds, dave, jgrahamc CC=golang-dev https://golang.org/cl/8166045 |
I think this fixes issue #2184. |
I was going create a patch for this, but noticed that the concurrent read/write loops handle this surprisingly well as is. A very easy improvement would be to flush headers immediately if expectsContinue during the initial write. One question regarding brafitz's earlier comment, do we actually *need* to block sending the body (seems ambiguous in the spec). I'd actually prefer the current behavior with the added flush, as it would get a head start on sending data, and it looks like the client still shuts down immediately upon a non 100-continue response. |
I believe this is the cause for issues I'm having PUT-ing to a server that redirects me. The body in the initial PUT request is prematurely consumed, despite my having set Expect: 100-continue. If there is Expect: 100-continue in the request, the body needs to be withheld from the request until a 100 Continue is received from the server. |
Although I'm not sure if it were a right implementation, I've sent my small patch for this issue. I hit this premature consuming issue on my project. So I would appreciate if someone review this CL. |
CL https://golang.org/cl/10091 mentions this issue. |
@bradfitz ping |
The Go tree is currently in freeze for the Go 1.5 release. The freeze started on May 1st, and this was sent after May 1st, and this was not tagged as a Go 1.5-blocking issue. As such, this has to wait until Go 1.6. I've marked that CL with R=close so it doesn't show up on our dashboard, but pinging this thread at any time will make it reappear. Please reply to this bug after August 1st and we can begin the code review. Thanks for working on this, though! |
@bradfiz OK, I catch on your timeline. I'll ping you again this August! @mattn Thanks for your pinging! |
I've been having issues with this as welI (using Go with CouchDB: http://stackoverflow.com/questions/30541591/large-put-requests-from-go-to-couchdb ) and I really hope this gets in sometime so I can remove the ugly hack-around in my code 👍 |
For golang-backed servers, is there a way to increase the max size before it starts the |
My body seems to be only 2000+ characters of JSON, so am not sure what triggers to |
@bradfitz can we get this in now?
|
I replied with some initial review feedback. |
@bradfitz Thank you for your feedback! I revised my patch a few weeks ago. |
Replied on Gerrit. |
@bradfitz Thank you for your review comments. I've just updated my CL on Gerrit. |
The text was updated successfully, but these errors were encountered: