Re: Comments on the HTTP/1.0 draft.

At 8:17 AM 12/7/94, wrote:
>To sum up Marcs argument:
>1) The performance hit is not too great

This is a fallacy. Simply put, it comes down to whether or not every single
character in a text transfer must be examined. There are N comparisons that
must be performed to place text in a cannonical form (one for each byte in
the file) versus ZERO comparisons if clients and servers simply tolerate
multiple line ends. How anyone can say this doesn't impose a noticable
impact on a server is beyond me.

To carry it further, simply write a C program that compares execution times
for block oriented reads from disk with no conversions versus character by
character I/O with CRLF conversions. The performance difference is worse by
almost 200% for the latter. Try it yourself.

>2) If there is no reason to do it and no reason not to then follow the spec.
>I do not want cannonicalisation under any circumstances. I have had my fill
>of systems that "canonicalise" trying to be "clever". Such systems break
>much much more than they mend.

I agree 100%. My whole point in participating in this thread has been to
advocate adding some verbage to the standard that documents the current
practice of tolerating mixed line ends as the prefered method. That's it.
Somehow this "cannonicalization" side show crept in and stirred up a
hornet's nest.

Chuck Shotton                             \
Assistant Director, Academic Computing     \   "Shut up and eat your
U. of Texas Health Science Center Houston   \    vegetables!!!"  (713) 794-5650 \

Received on Wednesday, 7 December 1994 07:51:54 UTC