Re: PERSIST: propose to make default

On Thu, 18 Apr 1996, 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.
> 
> 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.
> 
...

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

Your concerns are significant, but I don't understand how they are
affected by the Connection: header.  HTTP/1.1 clients and servers will
engage in both persistent and non-persistent connections.  They must
communicate to each other which type of connection they wish to use.
We are not discussing what the default *behavior* of a client should
be (persistent vs non-persistent).  That is up to the implementation.
We are only discussing how the chosen behavior is communicated from
client to server.  This communication doesn't require a header
for every request.  One type of connection can be the default and no
"Connection:" header is needed, while the other must be indicated by a
"Connection:" header. 

The discussion at hand is concerned with which should be the default
in the sense of which is communicated by the absence of a
"Connection:" header.  However this issue is decided, a client has the
option to make every connection non-persistent, if it chooses.
Whichever way this issue is decided I don't see how it would affect
error conditions.  A 1.1 client connecting to a server of unknown
vintage will have the same problems to deal with in either case.



John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Friday, 19 April 1996 06:07:14 UTC