Re: plain text protocol [was: Re: Performance analysis questions]
"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 3 Jun 1994 20:12:22 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406031809.AA20028@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: plain text protocol [was: Re: Performance analysis questions]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In message <Pine.3.89.9405310935.A9223-0100000@brazos.is.rice.edu>, Rick Troth
writes:
>
> Right. And I say that "plain text on the wire"
>is "ASCII, delimited by CR+LF". I think you agree, right?
>But we try to make our servers "liberal about what they accept"
>by making the CR optional. Fine. I say, take that one step
>further and make trailing white space insignificant. If you
>accept the former, how do you justify rejecting the latter?
I am suggesting we accept neither missing CR nor trailing whitespace.
Just fix the broken code.
If you want to hack in code in your servers that accepts missing CR,
and throws away whitespace at the end of a line, go right ahead.
I really wish you wouldn't though, as many developers use the "it
works with server X, so it must be right" methodology. So we will have
broken clients that work with hacked servers, and so new servers will
have to support the broken clients, and the spec documents will get
cluttered up with "NOTE: you really should add this hack and this
kludge if you want to interoperate with 80% of the existing
implementations."
I say: be precise, strict, and exact, in all distributed computations.
Suppose, in the future, we want to be able to take the md5 checksum of
the HTTP headers. If you corrupt the bytes by throwing away whitespace
at the end of a line, you defeat such efforts.
HTTP is currently based on a reliable 8-bit transport (TCP, not just
IP). Let's keep it that way.
Dan