W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 2000

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

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Tue, 20 Jun 2000 14:11:52 -0400 (EDT)
Message-Id: <200006201811.OAA20241@aleatory.research.bell-labs.com>
To: btaylor@neonsys.com
Cc: http-wg@cuckoo.hpl.hp.com
"Brad Taylor" <btaylor@neonsys.com> wrote:
  > 
  > 
  > 
  > 06/20/2000 11:57 AM
  > Brad Taylor@NEON
  > Brad Taylor@NEON
  > Brad Taylor@NEON
  > 06/20/2000 11:57 AM
  > 06/20/2000 11:57 AM
  > 
  > We are having a debate on browser behaviour and are trying to find what the
  > official spec says.  What we see is that browsers (ie5.0 and netscape) when
  > "POST"ing to our server construct a content-length and then append a 0d0a
  > to the end.  This 0d0a is not contained in the content length.  Is this
  > according to "SPEC"?  If so would someone be so kind as to point it out (I
  > am somewhat new to reading these specs).  Is this only going to occur for
  > POSTed data or will it also occur for other requests (GET, PUT,
  > etc.)....your consideration in advance is appreciated.

IIRC, early in HTTP/1.1 development there were servers that balked if
they received the message body associated with POST but the body didn't
end with a CRLF.  Or maybe it was that some clients erroneously sent
CRLF after every POST body.  Either way, RFC 2616 added the following
words (Sect. 4.1):

   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected. In other words, if
   the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.

The idea was that if there were pipelined requests, or multiple requests
on a persistent connection, the server should eat the extra CRLFs.

Dave Kristol
Received on Tuesday, 20 June 2000 19:13:21 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:38 EDT