Re: uh oh -- halp!

Marc Andreessen (marca@ncsa.uiuc.edu)
Thu, 9 Sep 93 00:28:05 -0500

Tony Sanders writes:
> [problem about supporting HTTP/1.0 and HTTP0 in same client]
> ...
> > > The result is that the socket gets confused and the client only ends
> > > up getting the first chunk of data (usually 1024 bytes).
> I think the client is getting ENOTCONN when the server does the close.
> You could work around this by detecting ENOTCONN and retrying without
> "HTTP/1.0". For performance you would probably want to cache a list of
> HTTP0 servers (though I wouldn't bother keeping it around between sessions).
>
> > 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.
> I don't think \r\n is the problem. Just set the connection to unbuffered
> (I'll bet you have it line buffered now) and flush when done building the
> request. However, I think you still get bitten if it fragments going out.
>
> Maybe someone with more TCP knowledge could dig into this and figure out
> another solution.

I'll try to pursue both of Tony's suggestions this weekend in Mosaic.
If neither solves the problem completely, I suggest as the easiest
solution that we require that existing HTTP0 servers *at least* be
upgraded to be able to accept full, multiline HTTP/1.0 queries, even
if they can't understand them.

If backward compatibility for HTTP0 servers is essential and such a
required partial upgrade situation wouldn't be acceptable, I then
suggest that browsers begin supporting a "http0:" URL type for the
sole purpose of communicating with old servers.

I make these specific suggestions because I think that changing either
HTTP0 or HTTP/1.0 at this point would be much more painful -- HTTP0
has served us well and is ideal for what it is (very simple, very
lightweight, and very easy to build shell scripts around -- my
proposed partial upgrade situation described above should leave those
qualities intact), and HTTP/1.0 is already achieving critical mass (by
virtue of Plexus and CERN httpd 2.x) and clients are already either
supporting it or will very soon.

I know Eric already disagrees with me already, and I'm sure others
will too, and I'm flexible on this -- *however*, I think we need to
value cohesion and stability more than almost any other factor at this
point, particularly as we are in the midst of a successful move to
HTTP/1.0 (which

Cheers,
Marc