Re: Luasocket - http.lua

[Adrian Sietsma <adrian_groups@...>]

D Burgess wrote:
> Hi Guys,
> Has anyone used Luasocket doing HTTP posts to webservers
> that do "100 Continue"? (e.g. IIS)
> I think the the current protocol code may require some tuning.
>
> I understand the sequence should be:
>
> C: send request header(s)
> S: read request
> S: 100 continue
> C: send post data
> S: read post data
> S: send response
> C: read response
>
> Luasocket code performs a sequence like:
>
> C: send request header(s)
> C: send post data
> S: read request
> S: read post data
> S: send response
> C: read response
>
> On reading the RFC it seems that the client should expect to
> to get a possible continue after writing the header and expect to
> get any number of continues while read the response.
>
> I used an IIS server (that I cant get to easily again) that
> the only response that Luasocket ever read on posts
> was the 100 continue.
>
> Does anyone have any experience with this?
>
> DB
----- RFC 2616 (8.2.3)---------------------

The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a 
client that is sending a request message with a request body to determine if 
the origin server is willing to accept the request (based on the request 
headers) before the client sends the request body. In some cases, it might 
either be inappropriate or highly inefficient for the client to send the 
body if the server will reject the message without looking at the body.

Requirements for HTTP/1.1 clients:


      - If a client will wait for a 100 (Continue) response before
        sending the request body, it MUST send an Expect request-header
        field (section 14.20) with the "100-continue" expectation.

      - A client MUST NOT send an Expect request-header field (section
        14.20) with the "100-continue" expectation if it does not intend
        to send a request body.

Because of the presence of older implementations, the protocol allows 
ambiguous situations in which a client may send "Expect: 100- continue" 
without receiving either a 417 (Expectation Failed) status or a 100 
(Continue) status. Therefore, when a client sends this header field to an 
origin server (possibly via a proxy) from which it has never seen a 100 
(Continue) status, the client SHOULD NOT wait for an indefinite period 
before sending the request body.

-- end RFC quote-----------------------------

However, I have seen servers that respond with an unsolicited 100 (Continue) 
when there is no post data involved, prior to generating a slow response. An 
error-tolerant HTTP client should probably allow for this.

Adrian