Re: PERSIST: propose to make default

On Sun, 21 Apr 1996, David W. Morris wrote:
> 
> 
> 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.
> 
...
> 
> 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
> 

Dave, there has been no proposal to change the semantic significance
of an unexpected close.  There has been no proposed change which impinges
in the slightest on RAS characteristics.

Please take a moment to seriously entertain the possibility that the
people saying you have misunderstood the proposal might be correct.

Here is another explanation of the proposed change: 

The HTTP/1.1 spec *could* (but doesn't) require that every request and
every response contain one of two mutually exclusive headers -- either
"Connection: close" or "Connection: persistent".  Which of the two to
send is, of course, entirely up to the sender.  Either side can choose
either as its default and either side can change what it is sending at
any time.

While this isn't what the draft spec does, it is very close. Since the
two connection headers are mutually exclusive, a "shorthand" can be
used to save a few bytes.  Instead of sending "Connection: close" the
absence of any Connection header implies that Connection: close should
be understood.  This is what is currently specified.  Other than
saving a few bytes nothing else is changed.  It is just as if that
Connection: close header were sent.  This shorthand has no effect on
error conditions, unexpected closes, TCP stacks, or the phase of the
moon.

Now, what has been proposed is a change in this shorthand.  Instead of
using the absence of a Connection header to mean "Connection: close"
it would be used to indicate "Connection: persistent" and the
"Connection: close" header would be explicitly sent.  The only thing
which has changed is encoding of information in headers.  There has
been no change in the default, or expected or error handling behavior
of either clients or servers.  The new proposal and the previous
proposal are logically equivalent.  Their headers communicate exactly
the same information (albeit in different encodings) and result in
exactly the same behavior in response to that information.

Let me say it again.  The proposed change affects the encoding of
headers, nothing more.  It's just as if we decided to change a header
to require that it be in French rather than English but didn't change
anything else.

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

Received on Sunday, 21 April 1996 17:19:58 UTC