W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: draft-ietf-httpbis-http2-latest, Request Header Fields | Re: draft-ietf-httpbis-http2-latest, Request Header Fields | Re: draft-ietf-httpbis-http2-latest, 5.5 Extending HTTP/2

From: Michael Sweet <msweet@apple.com>
Date: Mon, 28 Jul 2014 09:15:27 -0400
Cc: Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <BA08D20F-5E27-4302-BCA8-4214C8D943C4@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

I don't know, but RFC 2817 is pretty explicit about how to do a mandatory upgrade that applies to the connection and not to a particular resource:

   3.2 Mandatory Upgrade

   If an unsecured response would be unacceptable, a client MUST send an
   OPTIONS request first to complete the switch to TLS/1.0 (if

       OPTIONS * HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

I think that's the crux - "*" has a different semantic than "/", and in HTTP/1.x you can't pass an empty path on the request line.

On Jul 25, 2014, at 9:19 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-07-25 06:59, Michael Sweet wrote:
>> HTTP Upgrade
> And it couldn't have been "OPTIONS /"?
> There's nothing else in HTTP/1.1 that requires as many exceptions and special cases as the asterisk form... Cost/benefit etc.
> Best regards, Julian

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Monday, 28 July 2014 13:16:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC