Skip to content
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: work around spurious 100 CONTINUE #2184

Closed
kylelemons opened this issue Aug 24, 2011 · 13 comments
Closed

net/http: work around spurious 100 CONTINUE #2184

kylelemons opened this issue Aug 24, 2011 · 13 comments

Comments

@kylelemons
Copy link
Contributor

A single POST request to some servers (notably some versions of IIS and/or some versions
of ASP.NET) will generate an HTTP 100 CONTINUE whether or not the Expect: header for it
was sent, prior to the 200 which the client actually wants.

Example:
$ curl -i -H "Content-Type:application/json" -X POST -d$REDACTED http://foo/bar
HTTP/1.1 100 CONTINUE
Server: Microsoft-IIS/5.1
Date: Tue, 23 Aug 2011 16:22:13 GMT
X-Powered-By: ASP.NET
 
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Tue, 23 Aug 2011 16:22:13 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 470

{"redacted":true}

Currently, this will cause the persistent HTTP connection to either (a) return the
second request to the next request made on that connection or (b) print an unsolicited
response warning.

Expected behavior:
- Subsequent requests should not be broken by this.

Optional:
- The 200 and its associated information could be returned and the 100 ignored.
- The 100 could be returned, and the connection terminated (preventing other requests
from reusing the connection and returning bad data)
@adg
Copy link
Contributor

adg commented Aug 25, 2011

Comment 1:

Owner changed to @bradfitz.

Status changed to Accepted.

@bradfitz
Copy link
Contributor

Comment 2:

Is there a live server on the Internet I can verify that this happens with?  (before I
waste time writing a unit test to behave like that)
Are you 100% sure curl isn't sending the "Expect: 100-continue" header?  Curl may just
not show it with its -v verbose flag.

Owner changed to ---.

Status changed to WaitingForReply.

@kylelemons
Copy link
Contributor Author

Comment 3:

I'm trying to collect more information about the curl and IIS versions (it's hard
because they updated the system after this behavior was observed in order to fix it). 
While I'm not 100% certain that curl didn't send the Expect: header, we saw behavior
consistent with an unaccounted-for reply in two other applications.  The same curl
version and command also worked fine after an upgrade of IIS (as well as the two
clients).
The symptom in Go when connecting to a server like this is that many back-to-back
requests may receive the response from a previous request, and the HTTP package will
eventually start saying that it received unsolicited responses.
I will respond when I hear back about the version info, and then see if I can't find a
website on the internet using that version.

@kylelemons
Copy link
Contributor Author

Comment 4:

OS version: Windows XP Service pack 3
IIS version: 5.1
Curl version: 7.21.7.0
I haven't found a good way to find a web server that's running that version.  Alexa
seems to have the data, but I couldn't find a way to search it.  Any ideas?

@rsc
Copy link
Contributor

rsc commented Oct 6, 2011

Comment 5:

Status changed to HelpWanted.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2011

Comment 7:

Labels changed: added priority-later.

@patrickmn
Copy link

Comment 9:

I can confirm that this happens on (at least) IIS/5.1, even if the response that follows
is e.g. 405 Method Not Allowed. It also seems that, although not many servers do this,
sending a 100 Continue without an Expect appears to be valid according to RFC 2616.
CL here: http://golang.org/cl/5629061
This solves the issue when POSTing or PUTing to IIS/5.1, and the unit test replicates
its behavior.

@bradfitz
Copy link
Contributor

bradfitz commented Aug 7, 2012

Comment 10:

That CL might fix this issue, but any CL should probably also fix issue #3665, or at
least not be incompatible with its eventual fix.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 11:

Labels changed: added go1.1maybe.

@bradfitz
Copy link
Contributor

Comment 12:

Example provided by Andy Balholm:
# telnet webservices.lscsoft.com 80
Trying 198.31.208.201...
Connected to webservices.lscsoft.com.
Escape character is '^]'.
POST /productmanifest/productmanifest.asmx HTTP/1.1
Accept: text/xml
SOAPAction: "intuit.protax.lacerteservices/GetUpdateManifest"
Content-Type: text/xml
User-Agent: Borland SOAP 1.1
Host: webservices.lscsoft.com
Content-Length: 653
Proxy-Connection: Keep-Alive
Pragma: no-cache
HTTP/1.1 100 Continue
Date: Thu, 28 Feb 2013 17:55:41 GMT
X-Powered-By: ASP.NET

@rsc
Copy link
Contributor

rsc commented Mar 12, 2013

Comment 13:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

@bradfitz
Copy link
Contributor

Comment 14:

Fixed by revision 466040fd273e.
Finishing proper support for clients requesting "Expect: 100-continue" is issue #3665.

Labels changed: removed priority-later.

Owner changed to @bradfitz.

Status changed to Fixed.

@bradfitz
Copy link
Contributor

Comment 15:

This issue was updated by revision b80ce20.

Update issue #3665
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/8208043

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants