- From: Dave Kristol <dmk@allegra.att.com>
- Date: Fri, 19 Apr 96 10:32:43 EDT
- To: dwm@shell.portal.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
"David W. Morris" <dwm@shell.portal.com> wrote: > On Thu, 18 Apr 1996, Dave Kristol wrote: > > > IF YOU DISAGREE, please address your objections to the http-wg mailing > > list as quickly as possible. I review the proposal below. > > I disagree ... this is being proposed with far to little time to reflect > on inplications such as Roy Fielding raises with respect to clean and > unclean close. > > Having just recently spent days figuring out connection reset messages > from Netscape which turned out to be our server ignoring the > non-protocol extra CR-LF following POST content. I think this proposal > has significant potential for increasing the probability that unclean > close will become the norm. At best this will require significantly > more user friendly error handling. I don't see the [sorry] connection between this Netscape bug and the persistent connections issue. > > It seems to me that the fundamental problem here will be a HTTP/1.1 > client initiating a persistent connection with what turns out to be a > HTTP/1.0 server w/o knowing the server is able to handle the additional > data. If I recall correctly some of the issues raised earlier in > the two phase PUT discussions, an HTTP/1.0 server could close after > sending a brief response with the possiblity that the close would > result in a reset which could leave the client quite confused. I think John Franks described this quite elegantly. We all agree that we want persistent connections; we're just changing the default expectation. We've neither subtracted nor added problems. No matter which way you do it, clients and servers must deal with unexpected closes. > > Isn't this a relatively minor change which could be included with > HTTP/1.2? At that point there will be more general experience > deploying the more conservative approach as well as more experience > writing the code. I tend to be conservative, too, and I really hesitated before even putting forth the idea so late in the game, but the more I think about the "persistent by default" idea, the more comfortable I am with it. If we wait until HTTP/1.2, we will have 3 x 3 way combinatorics to worry about, which will increase the odds that different versions won't inter-operate correctly. > > So I would recommend against the change at this time but having said > my piece, I can accept the proposal as currently stated. Noted, and thanks for your comments. Dave Kristol
Received on Friday, 19 April 1996 07:43:59 UTC