Luasocket - http.lua

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Luasocket - http.lua

D Burgess-4
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


Reply | Threaded
Open this post in threaded view
|

Re: Luasocket - http.lua

Adrian Sietsma
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