Re: HTTP Content-length question...

Thus wrote: Rick Troth
>        NO,  it's not as much of a bug as you might at first suspect.
>Objects which are text/html should really be converted from LF line
>delimiters to CR/LF line delimiters.   That takes more work than just a
>quick stat(),  which is sufficient for image/gif and audio/au  (both of
>which are sent out as-is in binary).   It is unfortunate that a number
>of servers are  "lazy"  and don't  "canonicalize"  text/html correctly.

Well, it is unfortunate that more serious thought wan't given to
to the problems involved with this, perhaps.  Canonicalization of textual
line breaks, however, is no longer required under HTTP in general; instead,
all HTTP software is required to be able to recognize various different
common line endings when receiving bodies.  The result is not fantastic
or elegant but it's workable.

(Not that it matters too much with HTML, since aside from in <PRE> all
whitespace is created equal.  But, since HTML and HTTP are orthogonal,
it's still an issue.)

>>I can imagine that the problems can be due to server side includes in the
>>documents or dynamic documents generated by scripts.

Of course; there are limits on how much buffering one wants to do.
I'll use this moment to revisit my personal pet idea, which is that the
headers and status line and other metadata really should go after the
body of the response, not before it. :-)

- Marc

Received on Tuesday, 9 May 1995 00:48:08 UTC