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,

	I apologize for the lateness in posting this to the list.

If you view the open issues for HTTP/1.1 and the agenda for the Munich
meeting, you'll notice an issue called 'RE-VERSION'.  After discussion
with the HTTP editors, I was encouraged to raise this issue on the list
and as an open item for HTTP.

The RE-VERSION essentiall boils down to the meaning of the
version in an HTTP/1.1 response.

I, and the editors, understand that this issue was heatedly and
deeply discussed previously, however, over the course of time, 
I do not beleive that the previous resolution is sufficient.

To summarize, the draft now indicates that the response version
should be the highest version supported by the server, NOT
the version of the actual HTTP response.

My problem with this is based on the assumption in the draft
which dictates that the response version is hop-by-hop.

Overall, I beleive that the response version should indicate
the version of the response message.

The problems encountered so far, in addition to any confusion
because the 'response version', isnt the response version,
are as follows:

A client sends a 1.0 request, a 1.1 server responds with 
a 1.1 response. ( minus certain http/1.1 features/headers).

GET http://foo/foo.html HTTP/1.0
blah: blahvalue

HTTP/1.1 200 Ok
blah: blahvalue

content...

When going through a proxy, how is the proxy supposed to maintain
the hop-by-hop nature of the responses?

Worse, if a 1.0 proxy is in the stream, it will blindly pass
the 1.1 response code back to the client, and clearly fails
to honor the hop-by-hop nature of the response.
(this is the case with squid, netscape proxy, and presumable others)
Previously, the 1.0 didnt clearly define what the behaviour
should be in this case.

On deciding what to send in a 1.1 response to a 1.0 client,
there is no canonical list of things which a 
server must not send when sending a 1.1 labeled response
to a 1.0 server. There will surely be more than just
chunked encoding.. This seems like a nightmare for
proxy/server implementors dictating constant maintenance
releases to block new server reponse features/headers
from being sent to 1.0 clients.
( how can it be prepared to block something which hasn't
  been invented yet?)

The only reason I could find in the previous discussion
for this behavior was to allow partial implementations
to take advantage of some 1.1 features, but not all.
These days, since a great deal of the most contentious
features have been separated from the core http/1.1 draft,
I dont think its too much to ask for a reasonably
compliant implementation that can at least deal with
all the core http/1.1 headers/features.

Lets say Im implement a client that understands
cache-control ( IMHO a valuable 1.1 feature ),
but is 1.0 otherwise.  Should a server send
a cache-control: directive or the usual ugliness
of removing the last-modified: header? (or some other way).
Or should it send both? (subverting the usefulness
of the cache-control making it redundant)

Finally, with things the way they are, does the response
version actually mean anything useful?  How useful is knowing
what the highest version supported by the server?
Wouldnt knowing the version of the actual response message
be more useful and less ambiguous?

The way I see it we have these options:

1) leave as-is, keeping the broken hop-by-hop behaviour
   ( but vigorously specify what must not be sent to a 
	1.0 client in a 1.1 labeled response )

2) make the response version = the request version.

3) create an additional 'response-version: ' header
   to indicate the message version in use.

4) keep the same rules in the draft, but make our version
   2.0. ( which will mean that the server must send a 1.x
	response to a 1.x client )


Personally, I think the right thing to do is #2.
Yes, this will have some effect on the current implementations.
However:

1) the effect shouldnt put them in any worse position than they
   already are. ( still broken )

2) The IETF process draft/draft standard rfc/proposed standard rfc etc,
   is meant to allow changes.  Implementing a draft implies that changes
   will need to be made.


(Im sure Im missing some issues or other stuff.. feel free to comment :)