RE: CRLF on POST requests, where/how specified (repost from prior bad subject line)

As in the mail from Dave Kristol (20 juni 2000 20:12) this mechanism
complies with RFC2616. He points to section 4.1 (Message Types) where is
described that the empty lines (CRLF's) before the request-line should be
ignored. (He has got it right)
So let's assume (as the HTTP server) that those empty lines where send for
the next request. They should be simply ignored. (The last one seemed to be
finished, not?)

So if you check for this, you still comply with the latest HTTP/1.1 RFC.

But indeed the browsers don't work good, according to the RFC, but it should
work, if the HTTP servers (and proxies) have code for this implemented (as
MS-IIS/5.0 has, but Netscape-Enterprise/3.5.1 hasn't)

Joris Dobbelsteen



-----Original Message-----
From: Life is hard, and then you die [mailto:ronald@innovation.ch]
Sent: dinsdag 20 juni 2000 20:21
To: Fred Bohle
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: CRLF on POST requests, where/how specified (repost from
prior bad subject line)


On Tue, Jun 20, 2000 at 12:51:11PM -0500, Fred Bohle wrote:
>
>      No, not the CRLF between the headers and the body.  We are asking
>      about a CRLF that follows the body.  It does not seem to be in
>      the 1.0 spec, and the 1.1 spec seems to specifically prohibit it.
>      And yet, IE5 and Netscape both will send a CRLF after the body
>      for Content-type: application/x-www-url-encoded.

The spec clearly disallows this extra CRLF, i.e. it's a bug in those
browsers. However, there is an easy workaround which many people use:
when reading the request line, ignore all whitespace (or empty lines)
until you hit the actual request line.

>      What do other web servers do to handle this CRLF?  We find that
>      if we decide to close the connection with the end of the response
>      we generate, (Connection: close) and THEN the CRLF arrives from
>      the client, the TCP layer will generate a Reset packet.  This
>      causes (IE5 at least) the client to fail processing the response
>      we just sent.  So the application stops, dead in the water.

This is a little tricky, but not much. Basically you need to do a
shutdown on the socket, i.e. only close for sends; then you keep
reading from the socket (and just discard the data) until either you get
an EOF (in which case the client did the close), or until some timeout
(a few seconds) in case the client doesn't close the connection. Note
that this problem is a general problem (i.e. not limited to the extra
CRLF), because you can get the same effect when a client pipelines
requests.


  Cheers,

  Ronald


P.S. take a look at the Apache source: read_request_line() in
http_protocol.c
     for the first problem, and lingering_close() in http_main.c for
     the second - the comments are enlightening.

Received on Thursday, 22 June 2000 12:07:37 UTC