W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Comments on the HTTP/1.0 draft.

From: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
Date: Sun, 4 Dec 1994 07:27:58 -0600
Message-Id: <ab0771b8020210041115@[]>
To: Ari Luotonen <luotonen@neon.mcom.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> Chuck Shotton writes:
>> > IMHO, it should state that CR, LF, and CRLF should all be interpreted
>> > equally as EOL when used as line ends. This avoids any problems with
>> > machine dependent EOL symbols, and fairly represents the current practice.
>> > (It also avoids forcing clients and especially servers to do line-by-line
>> > translations of EOL for all outgoing response information, which is a BIG
>> > performance hit.)
>> Sounds reasonable to me.
>I object.
>So far, CRLF and LF have been understood as linebreaks.  In other
>words, LF is a linebreak, with possibly a preceding CR.  This is fine,
>even when used intermixed.
>If we change this in the proposed fashion, you will have ambiguity if
>these are inconsistently used;  imagine a situation when you have a
>file that begins with LF:
>Blaa: foobarCR
>This won't be ambiguous if you force the use of CRs and LFs to be
>consistent, but I think it's better to allow LFs and CRLFs intermixed,
>rather than allow CRs, LFs and CRLFs, but only one of them at a time.

First, if you don't interpret CR, LF, and CRLF (when they appear as
independent tokens) equally as line ends, some servers are going to be
forced to do an unnecessary amount of work.

Second, your example is flawed. There is NO ambiguity in this tiny EOL
grammar. A bare CR followed immediately by a LF is a CRLF "token" and
represents a line end. As such, it is not ambiguous. So your last two lines
in your example are not a problem.

A CR followed by anything except a LF is considered a line end. A LF
followed by ANYTHING is considered a line end. A CRLF followed by ANYTHING
is considered a line end. This represents the line end logic that every
client understands, and it prevents EVERY server from having to parse text
and modify line ends.

The logic for text file parsing becomes incredibly simple. If a CR is seen
with anything following it besides a LF, it's EOL. Otherwise, a LF always
indicates EOL.

I strongly suggest that the HTTP standard include a statement to the effect
that this is the approved way to tolerate cross-platform variations in text
file EOL tokens. Forcing a single platform's standards across all platforms
is unacceptable, especially when all clients and servers cope with the
problem now as described above.

Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."
Received on Sunday, 4 December 1994 05:27:33 EST

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