Re: PERSIST: propose to make default

    >An HTTP/1.1 agent that does *not* want to keep a connection open sends a
    >Connection: 1 [that's a change:  digit one, meaning "just one
    >connection"] request or response header.
    
    I'd probably prefer text over "1", whether it was "Connection:
    close" or "Connection: no-keepalive" or whatever.
    
This was discussed during today's editorial teleconference.  The
rationale was that this is (1) the most economical encoding we
could think of, and (2) it's legal according to the current grammar.
These might not be such great reasons, but it seems to work.

    I keep thinking there's something wrong with this that we don't see.
    
That's why we wanted to give people a chance to object.  If someone
seems something actually wrong with this, we won't do it.  But if
nobody can find anything wrong, it seems like the right thing to do.

    Why was the persistent connections group bothering with the
    Persist: <correct hostname> requirement if it's not an issue here?
    Were they ignoring the leveragable behavior of intermediary proxies
    downgrading the HTTP version of the request to the origin server to
    the proxies highest supported version?  Is that behavior absolutely
    universal amoung existing proxies?  Am I asking questions that have
    already been asked an answered? (probably)

The original motivation behind "Persist: hostname" was based on
shared misunderstanding of the HTTP version mechanism.  E.g.,
what gets sent according to this grammar:
       Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

The group that devised the Persist: hostname approach was (almost
entirely) under the mistaken belief that the HTTP-Version value
was end-to-end, but in fact it is hop-by-hop.  With only an end-to-end
version numbering scheme, we would have needed the hostname to check
that the hop-by-hop connection made sense.  But with a hop-by-hop
indication of HTTP/1.1, it's not needed.

Of course, this new approach would break if anyone had shipped
an HTTP implementation that identifies itself as HTTP/1.1 without
actually complying with the yet-to-be-issued HTTP/1.1 spefication.
But nobody is that foolish, right?

-Jeff

Received on Thursday, 18 April 1996 15:04:50 UTC