W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: PERSIST: propose to make default

From: Dave Kristol <dmk@allegra.att.com>
Date: Fri, 19 Apr 96 10:32:43 EDT
Message-Id: <9604191432.AA21910@aleatory.tempo.att.com>
To: dwm@shell.portal.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/261
"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
  > 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC