handling 100 Continue (in HTTP client)

[Andy Balholm]

If I send an HTTP request with DefaultTransport.RoundTrip and receive a 100 Continue response, how can I then send the request body? Or is this something that's not implemented yet?

[Kyle Lemons]

Are you sending Expect: 100-continue?  I don't think the library supports this, but if it did, it would need to do the right thing when you RoundTrip with a Request whose header is expecting a continue; I don't think you can do it yourself at that level of the API.

On Wed, Feb 27, 2013 at 5:18 PM, Andy Balholm <andyb...@gmail.com> wrote:

If I send an HTTP request with DefaultTransport.RoundTrip and receive a 100 Continue response, how can I then send the request body? Or is this something that's not implemented yet?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andy Balholm]

On Wednesday, February 27, 2013 5:21:29 PM UTC-8, Kyle Lemons wrote:

Are you sending Expect: 100-continue?  I don't think the library supports this, but if it did, it would need to do the right thing when you RoundTrip with a Request whose header is expecting a continue; I don't think you can do it yourself at that level of the API.

No, I'm not sending Expect: 100-continue. The server sends 100 Continue in response to a POST whenever the client supports HTTP 1.1. This is a SHOULD NOT (but not a MUST NOT) in the RFC.

RFC 2616, section 8.2.3: 

An origin server SHOULD NOT send a 100 (Continue) response if
        the request message does not include an Expect request-header
        field with the "100-continue" expectation, and MUST NOT send a
        100 (Continue) response if such a request comes from an HTTP/1.0
        (or earlier) client. There is an exception to this rule: for
        compatibility with RFC 2068, a server MAY send a 100 (Continue)
        status in response to an HTTP/1.1 PUT or POST request that does
        not include an Expect request-header field with the "100-
        continue" expectation. This exception, the purpose of which is
        to minimize any client processing delays associated with an
        undeclared wait for 100 (Continue) status, applies only to
        HTTP/1.1 requests, and not to requests with any other HTTP-
        version value.

[Patrick Mylund Nielsen]

https://code.google.com/p/go/issues/detail?id=2184

I haven't had a chance to revisit on a machine with IIS yet.

--

[Andy Balholm]

On Feb 27, 2013, at 7:59 PM, Patrick Mylund Nielsen <pat...@patrickmylund.com> wrote:

https://code.google.com/p/go/issues/detail?id=2184

I haven't had a chance to revisit on a machine with IIS yet.

Well, if what you're lacking is a server to test against, Intuit has provided one:

# 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

[Brad Fitzpatrick]

On Thu, Feb 28, 2013 at 9:43 AM, Andy Balholm <andyb...@gmail.com> wrote:

On Feb 27, 2013, at 7:59 PM, Patrick Mylund Nielsen <pat...@patrickmylund.com> wrote:

https://code.google.com/p/go/issues/detail?id=2184

I haven't had a chance to revisit on a machine with IIS yet.

Well, if what you're lacking is a server to test against, Intuit has provided one:

Hah. Thanks.

We could've faked one, but I wanted to see whether this happened in the wild first.  Apparently yes.

I'll add this to the bug.