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

Fred Bohle@NEON
06/20/2000 12:51 PM

Scott,

     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.

     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.



Fred Bohle





"Scott Lawrence" <lawrence@agranat.com> on 06/20/2000 12:36:45 PM

To:   Brad Taylor/Neon, http-wg@cuckoo.hpl.hp.com
cc:    (bcc: Fred Bohle/Dev/Neon)

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





See RFC 2616 ( http://www.innosoft.com/rfc/rfc2616.html#sec-4.1 )

Quoting:

----
Request (section 5) and Response (section 6) messages use the
generic message format of RFC 822 [9] for transferring entities (the
payload of the message). Both types of message consist of a
start-line, zero or more header fields (also known as "headers"), an
empty line (i.e., a line with nothing preceding the CRLF) indicating
the end of the header fields, and possibly a message-body.


        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
----
The CRLF that separates the headers from the body is not part of
either.  Since it is not part of the body, it is not included in the
content length.

--
Scott Lawrence      Director of R & D        <lawrence@agranat.com>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/

Received on Tuesday, 20 June 2000 10:52:57 UTC