Re: HTTP version number

Roy T. Fielding:
>[Koen Holtman:]
>> So under the current scheme, with 1.0 software in the request chain
>> undetectable, even if 95% of the software is 1.1, the service author
>> _will still have to guess_ which protocol elements can be safely used
>> in a response, as the response may go to some ancient 1.0 client.
>
>No.  All 1.1 elements which are not specific to the nearest-neighbor
>in the communication chain are already safe to be used in a response
>to any 1.0 client.

No.  Numerous 1.1 elements and 1.0 elements which are not specific to
the nearest-neighbor in the communication chain are _unsafe_ when used
in a request chain containing a 1.0 client. (I define `unsafe' as
`you do not know what will happen if you use it'.)

HTTP/1.0 will be an informational standard, and this means that, in
theory, you cannot safely use anything in a response to a HTTP/1.0
client.  In practice, only a number of things cannot be safely used,
for example

 - 301 and 302 responses to a POST request
 - the Expires header (many 1.0 clients will ignore it)
 - 200 responses to a POST request (some 1.0 clients will cache them)

are unsafe with the collection of 1.0 clients in operation now.
Future 1.0 clients may add new unsafe elements without violating any
standard.

>We cannot introduce unsafe elements to the
>protocol until we are willing to change the version to 2.0,

Unsafe elements were introduced when 1.0 was made informational.
There is nothing you can do about that.  In particular, it won't help
at all if you lecture me about how bad it is to propose the
introduction of unsafe elements.  I do not propose such things, I
merely assert that we already have them.  I am painfully aware of the
consequences of unsafety: I have spent two months in 1994
investigating unsafety of 1.0 protocol elements, and this was when we
had only 4 major browsers.

I want a protocol in which the presence of 1.0 clients in the request
chain is detectable, so that, in 1998, it won't be necessary anymore
to spend two months investigating unsafety of 1.0 protocol elements,
just because there is no reliable way to avoid serving the 3% of users
still using broken 1.0 software.

[...]
>> I propose use of the version number in the request-line to indicate
>> the _minimal_ protocol version used in the request chain.
>
>No, that is not acceptable to me.  It prevents forward progress and
>efficient introduction of protocol-upgrading proxies

I believe you mean to say "it breaks Upgrade:".  I just went over the
spec, and you seem to be right on this.

OK, I understand your objections to changing the rules for the version
number in the request line.  I hope you understand my reasons for
wanting to detect 1.0 clients.  So here is a new proposal:

We add the following requirement for proxies:

If a proxy upgrades a request message from HTTP/1.0 to HTTP.1.1, it
must include a request header

 Upgraded-From: HTTP/1.0

in the upgraded request message.  Such an Upgraded-From header could
also be useful if a request message is upgraded through the Upgrade
header mechanism.  Thus I get to the following text for the 1.1 draft:

 10.x Upgraded-From

 The Upgraded-From request header must be used by a proxy upgrading a
 request message to a different protocol version to record the
 original protocol version of the request message.  The information in
 this header can be used by servers when generating response message
 status codes or headers that must be understood by all clients in the
 response chain.

   Upgraded-From: 1#product

 If a proxy upgrades a request message that already contains an
 Upgraded-From field, it must add the protocol version upgraded from
 to the end of the Upgraded-From field.  For example, a request
 message upgraded from HTTP/1.0 to HTTP/1.1 by a proxy earlier in the
 request chain, and upgraded to HTTP/1.2 by the current proxy, must
 contain the request header

   Upgraded-From: HTTP/1.0, HTTP/1.1

With this header, my detectability requirements are met.  Roy, is this
header acceptable to you?

> ...Roy T. Fielding

Koen.

Received on Saturday, 16 March 1996 06:58:16 UTC