Re: plain text protocol [was: Re: Performance analysis questions]
Rick Troth <troth@rice.edu>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 3 Jun 1994 21:04:30 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Pine.3.89.9406031336.A4606-0100000@brazos.is.rice.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: troth@rice.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rick Troth <troth@rice.edu>
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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
> I am suggesting we accept neither missing CR nor trailing whitespace.
> Just fix the broken code.
Thank's for being consistent.
> I say: be precise, strict, and exact, in all distributed computations.
You can't do that in a truly heterogeneous world (or network).
I'm not saying it's right to be imprecise, lax, or inexact, but that's
what you're going to run into. Be a boy scout, "Be Prepared".
> 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.
You're saying that HTTP is -not- a plain text protocol.
If it's not a plain text protocol, then GET should have been
something like (in C):
sprintf(GET_REQUEST,"%c%s",0x01,URL)
where 0x01 is just some arbitrary bit pattern that we chose
to mean "GET". But it's not. Blame this on Tim if you don't like it.
Going with a plain text protocol made HTTP 1) easier to debug, and
2) easier to extend. The same is true for ignoring trailing white
space. (optional CR is just a courtesy we give to UNIX, I s'pose)
> HTTP is currently based on a reliable 8-bit transport
> (TCP, not just IP). Let's keep it that way.
TELNET is currently based on a reliable 8-bit transport,
but you don't expect your shell to be as strict as you seem to want
HTTP to be. HTTPD's not a shell? Sure it is. "Shells take their
input from humans only", not true!
> Dan
BTW, all I'm suggesting is that we retain (formally)
one aspect of current behaviour. The servers I've been able
to check don't care about trailing white space; some even allow
the blank line (end-of-header) to be just blank (not empty) already.
Let's keep it that way.
--
Rick Troth <troth@rice.edu>, Rice University, Information Systems