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