Re: uh oh -- halp!

marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Thu, 9 Sep 93 00:28:05 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9309090528.AA09618@wintermute.ncsa.uiuc.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: uh oh -- halp! 
In-reply-to: <9309082104.AA01315@austin.BSDI.COM>
References: <9309082104.AA01315@austin.BSDI.COM>
X-Md4-Signature: f5e30f544f88dc44baf5bc465f51dd0e
Status: RO
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 provides lots of expansion room into the future).

Cheers,
Marc