[5703] in www-talk@info.cern.ch
Re: CRLF vs LF was: Re: holding connections open...
daemon@ATHENA.MIT.EDU (hallam@dxal18.cern.ch)
Mon Sep 19 10:56:39 1994
Date: Mon, 19 Sep 1994 13:49:42 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: hallam@dxal18.cern.ch
From: hallam@dxal18.cern.ch
To: Multiple recipients of list <www-talk@www0.cern.ch>
>Now, there's no reason in principle why the Web can't loosen RFC822
>restrictions, but it's a slippery slope, and I'm not sure it's worth the
>marginal benefits it brings in this case. At any rate, one should be
>clear that the RFC822 rules are in fact quite strict on this matter.
Ooops, wrong spec, I think its in the `server tolerance' bit of the HTTP spec.
Ie servers must try to be as tolerant as possible when interpreting a
request. They should of course produce CRLF.
I don't see how it causes problems anyway since the string is CRLF so if you
get an LF you should simply imply a CR (if you are being tolerant). I don't
see that any ambiguity arises which was the main point put.
It would be nice if the servers had an equivalent of the `bad html' message
for http. So that when connecting to a sloppy server there would be a not to
say so.
I hope nobody interpreted what I said as implying that people should not send
a CRLF, the point is really that peoples servers should not go falling over
they only get an LF.
Phill
