Re: PERSIST: propose to make default

On Fri, 19 Apr 1996, Dave Kristol wrote:

> "David W. Morris" <> 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.

I didn't and don't call it a Netscape bug. It the reference was made in
an obviously unclear attempt the difficulties of providing user friendly
and helpful diagnosis when one of the peers of a connection receives
an unexpected close/reset.

>   > 
>   > 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.

THe difference is whether clients and servers can report unexpected closes
as an error and provide diagnostic information or if the unexpected closes
must be tolerated silently for the correct operation of the protocol. This
change to the default behavior will make diagnosis of network failures
even more difficult then they are. What exactly is the error analysis
support you would expect from a client or server when the protocol is
so blase about unexpected closes.

Quite simply, my increasing discomfort with this proposed change stems from
the change in semantic significance for what is basically a communications
failure ... the unexpected close.

>   > 
>   > 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.

I would call increasing the dependancy on unexpected close more like
inter-tolerate than inter-operate.

>   > So I would recommend against the change at this time but having said
>   > my piece, I can accept the proposal as currently stated.

I can only hope that the developers responsible for their product's RAS
characteristics (Reliability, Availability, Servicability) have seen
and thought about this proposal. We haven't provided much time.

Dave Morris

Received on Sunday, 21 April 1996 12:26:49 UTC