Re: plain text protocol [was: Re: Performance analysis questions]
Rick Troth (troth@rice.edu)
Fri, 3 Jun 1994 14:02:22 -0500 (CDT)
> 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