Re: Comments on the HTTP/1.0 draft.

>> 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>

Received on Thursday, 1 December 1994 20:32:48 UTC