Re: Comments on the HTTP/1.0 draft.

At 11:35 PM 12/1/94, Albert Lunde wrote:
>Regarding line-break treatment, I agree that it is possible to
>write a finite state machine which can usefully interpret
>CR, LF, CRLF (but not LFCR) as end-of-line breaks.
>I wrote such a program a year or two back to unscramble people's
>mistakes with FTP ;)
>However, I think this is too much of a burden to add to client

Not at all. Show me a single client that doesn't already do this. As Roy
says, it is also an issue of scale. A client can more effectively do this
translation once for a single user than a server that must do it thousands
of times an hour for all users.

>If we were writing a standard from scratch, I'd insist on one
>line break.

Wouldn't be a very efficient standard when implemented. Every compiler I'm
aware of supports multiple representations for EOL. Why shouldn't the
parsers associated with HTTP and HTML be equally tolerant? HTML files are
"source code" for the HTTP "compiler." If you demand a standard EOL token,
why don't we make sure that text starts in card column 6 while we're at it?
:) Tolerance is the order of the day here. It makes things more efficient
for servers and MUCH easier for users.

>It would be nice of HTTP and HTML standards agreed on the treatment
>of line breaks in text/html....

I agree... as long as it accomodates all the representations for EOL in
current practice. The current attitudes towards this seem to be very
Unix-centric and this is very wrong. It won't be long before we see HTTP
servers that have NOTHING to do with a local file system and reside on top
of a DBMS or some other non-traditional object store. I'm not aware of ANY
commercial DBMS implementations that use LF as EOL. This diverges from the
topic a bit, but I'm trying to make a point that it is NOT sufficient to
accomodate only a portion of the platforms in use (e.g., Unix) in the
standard as they will represent a decreasing proportion of Web platforms as
the Web grows.

Chuck Shotton                           "I am NOT here."

Received on Sunday, 4 December 1994 06:02:00 UTC