Re: Comments on the HTTP/1.0 draft.
Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Thu, 01 Dec 1994 20:21:10 -0800
>> 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:
>
> ...CRLF
> Blaa: foobarCR
> CR
> LF
>
> 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.
>
> -- Cheers, Ari --
We are only talking about the object-body here -- the spec already
requires that headers be CRLF terminated (with LF-only tolerated).
The suggestion up above is for clients to look for line breaks in the
object-body (i.e. when displaying text/plain) according to a perl regular
expression like:
if ( /\r?\n?/ ) { print "\n"; }
(i.e. match CRLF, CR, or LF (but not LFCR) and treat it as a newline).
In other words
if ((c = getc(IN)) == LF)
putc('\n');
elsif (c = CR)
{
if ((c2 = getc(IN)) == LF)
putc('\n');
else
{
putc('\n');
putc(c2);
}
}
else output(c);
(well, okay, so I've ignored EOF, but you get the drift).
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>