Re: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

I now do not think that "upgrade" needs to be a pseudo header.

The reason I proposed having :upgrade: pseudo header was due to my
understanding that HTTP/2 prohibited hop-by-hop headers, and that we
are trying to revive the "upgrade" hop-by-hop header of HTTP/1 by
trying to implement Websocket (or a generic upgrade) on HTTP/2. It
seemed to me that defining it as an extraordinary header (i.e. pseudo
header) seemed to make sense.

But reconsidering this, I now believe that what we are trying to
define is an end-to-end upgrade of a stream. In H2WS, we use a
SETTINGS parameter for hop-by-hop negotiation.

So now, it seems to me that defining the header as an ordinary (i.e.
non-pseudo) header is fine.


2017-11-12 6:24 GMT+08:00 Patrick McManus <mcmanus@ducksong.com>:
> I'm with Mike. It also gives the rather more radical example of changing the
> layout of the HEADERS frame, which is not a manifestation of the enumerated
> mechanisms either and would certainly violate otherwise normative
> requirements of non-extended 7540.. the "limitations" it is referring to is
> fundamentally the need for opt-in for this kind of change - not a limitation
> against the change itself.
>
>
> On Sun, Nov 12, 2017 at 5:33 AM, Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> "any aspect of the protocol" seems clear enough to me.  Though perhaps it
>> was an oversight not to have a registry for new pseudo-headers.
>>
>> -----Original Message-----
>> From: hurtta@[192.168.0.26] [mailto:hurtta@[192.168.0.26]] On Behalf Of
>> Kari Hurtta
>> Sent: Sunday, November 12, 2017 5:07 AM
>> To: HTTP Working Group <ietf-http-wg@w3.org>
>> Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; Patrick McManus
>> <mcmanus@ducksong.com>; Cory Benfield <cory@lukasa.co.uk>
>> Subject: Extending HTTP/2 | Re: New Version Notification for
>> draft-mcmanus-httpbis-h2-websockets-00.txt
>>
>> >> Doesn’t the introduction of a new pseudo-header field violate RFC
>> >> 7540 Section 8.1.2.1, which says endpoints MUST NOT generate new
>> >> pseudo-header fields?
>> >>
>> >> Or is the position that that MUST NOT implicitly applies only if
>> >> there are no negotiated extensions in use?
>> >>
>> >>
>> >right - negotiating an extension via 7540 section 5.5 is an opt-in
>> >procedure that lets you do just about anything you agree to..
>>
>> I note that new pseudo-headers are not mentioned.
>>
>> 5.5.  Extending HTTP/2
>> https://tools.ietf.org/html/rfc7540#section-5.5
>>
>> "   HTTP/2 permits extension of the protocol.  Within the limitations
>> "   described in this section, protocol extensions can be used to provide
>> "   additional services or alter any aspect of the protocol.  Extensions
>> "   are effective only within the scope of a single HTTP/2 connection.
>>
>> and
>>
>> "   Extensions are permitted to use new frame types (Section 4.1), new
>> "   settings (Section 6.5.2), or new error codes (Section 7).  Registries
>> "   are established for managing these extension points: frame types
>> "   (Section 11.2), settings (Section 11.3), and error codes
>> "   (Section 11.4).
>>
>> This makes unclear that extensions are permitted to use new pseudo header
>> fields or other elements mentioned on HTTP/2 which are not listed on here.
>>
>> Of course you can change anything by saying that specification updates RFC
>> 7540.
>>
>> / Kari Hurtta
>>
>



-- 
Kazuho Oku

Received on Sunday, 12 November 2017 00:27:48 UTC