W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Issue 240: Migrate Upgrade details from RFC2817

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 31 Oct 2010 11:06:08 +0100
Message-ID: <4CCD3F90.5060403@gmx.de>
To: Adrien de Croy <adrien@qbik.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Adrien,

On 31.10.2010 00:28, Adrien de Croy wrote:
> one comment I'd like to make.
> When I first read the definition for Upgrade in RFC2616, I switched off
> as soon as I saw the word "additional communications protocols" which
> didn't make any sense to me.
> IMO it should read "alternative communications protocols", since if the
> header is acted on, the protocol will be changed to rather than added.

I don't think it makes a big difference; these are communication 
protocols in *addition* to HTTP/1.1, right?

> Also, this is a classic case of why HTTP/1.1 intermediaries MUST strip
> headers matching tokens in the Connection header. It makes me wonder
> what will happen if an HTTP/1.0 proxy receives one of these and forwards
> it. Is there a requirement on servers to ignore upgrade on an HTTP/1.0
> request?


"A system receiving an HTTP/1.0 (or lower-version) message that includes 
a Connection header field MUST, for each connection-token in this field, 
remove and ignore any header field(s) from the message with the same 
name as the connection-token."


> I also wonder what an HTTP/2.0 proxy should send upstream when receiving
> Upgrade: HTTP/2.0 in an HTTP/1.1 request.

I don't think we need to answer that know.

> The example is also slightly confusing.
> It refers to "Upgrade: HTTP/2.0"
> however the registered key-word with the IANA is only "HTTP", and
> doesn't include any version number.

Yes. RFC2817 and RFC2616 did not agree on whether the registry takes 
tokens or products. The current registry contains both.

According to RFC2616: "This specification only defines the protocol name 
"HTTP" for use by the family of Hypertext Transfer Protocols, as defined 
by the HTTP version rules of Section 3.1 and future updates to this 

> I don't see any discussion for the production of "product" in the BNF
> for Upgrade, which would need to include version number (as opposed to
> it being optional in the product production in S 3.8) in order for this
> example to be correct according to the current IANA registry, or would
> we need to register a separate value with the IANA of "HTTP/2.0" (which
> is in keeping with the way TLS/1.0 is registered)? On that note, it may

I think the idea is that the prefix "HTTP" is reserved for HTTP, and 
future versions of HTTP can then register HTTP with a version in the 
IANA registry.

> be prudent to consider versioning in this aspect for WebSocket. At the
> very least there is inconsistency about how the 3 tokens are currently
> registered, with TLS including version and the others not.

Yes. Assuming we want to allow both formats, we may have to clarify the 
registration procedure. Proposals are welcome.

> Without version number, registering the bare "HTTP" token is probably of
> little use. Especially since if the version defines aspects such as new
> (incompatible) framing etc, then the version is a key part of the actual
> protocol being referred to and can't really be omitted. In that sense,
> if a server received
> Upgrade: HTTP
> then the only sensible thing to do is ignore it.


> It makes me wonder whether the BNF for Upgrade should have referred to
> product or some other production requiring version, and being designed
> to be the name of a protocol (non-optional version) rather than the name
> of a product. c.f.
>         product         = token ["/" product-version]
>         product-version = token

I'm not sure I understand the issue, except for the lack of consistency 
(which is historic).

A software component needs to understand the whole "product", no matter 
whether it's token or token/token. If it does, it will know what do do 
anyway, right? There's no generic processing possible here.

Best regards, Julian
Received on Sunday, 31 October 2010 10:06:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC