Re: uh oh -- halp!

[email protected]
Wed, 08 Sep 93 15:01:24 -0500

> From: [email protected] (Marc Andreessen)
> To: [email protected]
> Subject: uh oh -- halp!
>
> Major problem with HTTP/1.0 and HTTP0 in the same client:
>
> Sending a HTTP/1.0 request to a HTTP0 server can result in problems
> with the client and server are sufficiently far apart on the network,
> apparently because of the following:
>
> (a) Client sends 'GET /foobar HTTP/1.0' CR LF.
> (b) Server says, aha, I'm supposed to send data, and starts sending.
> (c) Clinet sends the rest of the HTTP/1.0 request, including the
> Accept fields, etc., followed by the HTTP/1.0 terminating (end of
> request) blank line.
>
> The result is that the socket gets confused and the client only ends
> up getting the first chunk of data<(usually 1024 bytes).
>
> Lots of people are seeing this with Mosaic 2.0p3, and Bill Perry's
> Emacs client hits the same situation in some cases. So it seems to be
> general enough to be a real pain in the butt...
>
> Any ideas?
>
> Possibilities I see:
>
> (a) Everyone upgrade to HTTP/1.0 pronto, and everyone forget about
> HTTP0 forever.
> (c) Change all existing HTTP0 servers to catch the HTTP/1.0 request
> field when it's sent and wait for the rest of the HTTP/1.0 request
> to come through (but ignore it).
> (c) Change HTTP/1.0 to only send a single CR LF in the entire
> request datastream.
>
> None of these seem palatable to me. Thoughts?
>
> Thanks,
> Marc
>

Well, I'll start this off.

In private conversation with me, Marc has convinced me that HTTP0 is
useful enough for quick shell script special purpose servers that we need
to keep it around as a viable protocol. That being the case. It is also
vital that HTTP/1.0 clients still be able to talk to these servers.

I feel we need to bite the bullet and be willing to change one of these
protocols. Both are already somewhat established, and changing either
of them will require the cooperation of all the current browser and server
writers.

1) To change the HTTP/1.0 protocol to use a different separator between
accept fields, and to use CR LF as a terminator. This means getting new
versions of all the servers and clients, and also means getting all
existing HTTP/1.0 servers upgraded. Anyone know the install base
out there? This will cause lots of user headaches until all the servers
get upgraded.

2) Change HTTP0. As I understand it, an HTTP0 server right now, to
process an HTTP/1.0 request reads first the command (Usually GET),
Then the URL. It throws away everything from the URL to CR LF.
We could modify this slightly to instead throw away eveything up
to the terminator for HTTP/1.0 (Which This would mean upgrading all the current HTTP0 servers and shell
scripts. It should be an easy update, just change the terminating
sequence. The biggest headache here is what to do about old HTTP0
clients. They would hang on the new HTTP0 servers, because they would
never send the right terminating sequence. Are their any browsers
out there that are not planning to move to HTTP/1.0 in the coming year?

If the number of HTTP/1.0 servers is small (less than 200), then I would
prefer option 1. If both have about equal server numbers I would prefer
option 2, because I would rather cause headaches for users of old
(out-of-date) software than for users of our new stuff. (I.E. Everyone
we have already sold on HTTP/1.0). For document writers who have to deal
with stubborn old servers who refuse to upgrade, we could add a http0://
url type to the browser that would always talk that protocol. Of course
this will break all the current documents that assume all http is created
equal.

Any other opinions?

Eric