Re: Comments on the HTTP/1.0 draft.

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

RIGHT! object-body only. Sorry if I was being confusing by not restating
this in my posts. Header fields are never a problem because they are
generated and can always be generated "correctly." On the other hand,
converting a 2 meg postscript file's line ends every time it is requested
will start to add up.

I can't understand how it'd be "easier" to force some servers to do this
work rather than to accomodate it with a simple statement in the standard.
Defining tolerant EOL handling has absolutely no effect on existing
clients, since they support this already anyway. And it probably won't have
ANY effect on servers since it is primarily oriented towards object-bodies
that they return by snarfing data directly off the disk.

-----------------------------------------------------------------------
Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

Received on Sunday, 4 December 1994 05:45:59 UTC