RE-VERSION

-- 
-----------------------------------------------------------------------------
Josh Cohen <josh@netscape.com>		      Netscape Communications Corp.
http://people.netscape.com/josh/
                                "You can land on the sun, but only at night"

Greetings,
 At Munich, we discussed the RE-VERSION issue. The issue is
should the response version be the server's version advertisement
or the message version.

After yet another heated discussion:), my impression is that
in the absence of a compelling bustage, the current
semantics should remain the same, ie response version = server version.

I also want to note, that (IMHO) most people felt that they
would prefer a message version, but at this stage, it was
too late to change it. (in the absence of a compelling bustage).

So, to close the issue, I'd like to get ready to last call this
issue.  To do so, Id like to move forward, if the following
issues are deemed resolved:

(These are possible problems that we run into with the
current semantics, along with ways of making them work)

The current proposal:
 Leave the version as-is, but clarify that proxies MUST upragde
all requests to the proxy's highest version.

Issues;

issue: cache-label: How does a proxy label a cache entry, and when can 
it use the cache entry to satisfy subsequent requests.
 
solution: as long as the proxy always upgrades to the highest version,
 it can be confident that it has the 'best response' in its cache
 and can satisfy both http/1.1 and http/1.0 requests in the future.

issue: chunked POST: this was the only concrete use where
 the server version is useful.  Unfortunately, even 1.1 proxies/servers
 may not support a chunked POST.  Since this is a fringe case, 
 its not a show stopper either way.  Another method, possibly
 OPTIONS is necessary to determine if a chunked post will succeed.

solution: none as-is

issue: keep-alives in client
 If you have:
 1.1 client   -> 1.0 proxy -> 1.1 server
 The client will issue a 1.1 request, the proxy will downgrade it
 to 1.0, and the server will respond with a 1.1 response.
 (but 1.0 compatible, ie no chunked encoding )
 The proxy will then blindly forward the response ( 1.1) back to 
 the client.

 If the client was assuming persistent connections, but the 1.0
 proxy doesnt support keep-alives, how should the client behave?
 How can it recognize that its request path it really 1.0 and not
 1.1?
 Presumably, the client will assume 1.1 and that persistent connections
 are OK, but the proxy willl be closing the connections after each
 request.

solution: The client will recognize the closed connection ( at some point )
 and re-open a new connection.  Unfortunately, some clients will deal
 with this in an extremely unpleasant manner, not recognizing the 
 closed connection immediately.

 In general, how should the connection semantics be handled?
 The client now beleives it has a 1.1 session, but in fact, it does
 not.

issue: keep-alives in server
 By default, persistent connections are supposed to be used in 1.1.
 When a server receives a downgraded request from a proxy, which
 came from a 1.1 client, should it respond with a connection: close?

Issue: (related) the draft says that connection and response version 
 are hop-by-hop, but it also says that a proxy may act as a 'tunnel'
 at any time. These are contradictory, since proxies may downgrade
 a request, but tunnel the response, which breaks the hop-by-hop 
 nature of response version.