- From: Josh Cohen <joshco@gmail.com>
- Date: Fri, 11 Oct 2024 21:46:20 -0400
- To: Ilari Liusvaara <ilariliusvaara@welho.com>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CAF3KT4S9m3O55q=4Zz0FtzShZNLzh=0QKh_xCFE5iR7LaDkejQ@mail.gmail.com>
Ilari said: "For HTTP/2, that was one of the things removed in RFC9113 (the original RFC7540 had that capability)." That would be raining on the Symmetric HTTP parade (: However, I looked through the RFCs and I didn't see that. RFC9113 still mentions even numbered IDs for server initiated streams. I see a difference in the SETTING param for ENABLE_PUSH, but it doesn't prohibit it. Can you steer me towards where server initiated streams are prohibited? Below are the referenced sections: RFC7540 https://datatracker.ietf.org/doc/html/rfc7540#section-5.1.1 > Streams are identified with an unsigned 31-bit integer. Streams initiated > by a client MUST use odd-numbered stream identifiers; those initiated by > the server MUST use even-numbered stream identifiers. https://datatracker.ietf.org/doc/html/rfc7540#section-6.5.2 > SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable > server push (Section 8.2 > <https://datatracker.ietf.org/doc/html/rfc7540#section-8.2>). An > endpoint MUST NOT send a > PUSH_PROMISE frame if it receives this parameter set to a value of > 0. An endpoint that has both set this parameter to 0 and had it > acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a > connection error ( > PUSH_PROMISE frame if it receives this parameter set to a value of > 0. An endpoint that has both set this parameter to 0 and had it > acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a > connection error (Section 5.4.1 > <https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.1>) of type > PROTOCOL_ERROR. > > The initial value is 1, which indicates that server push is > permitted. Any value other than 0 or 1 MUST be treated as a > connection error (Section 5.4.1 > <https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.1>) of type > PROTOCOL_ERROR. RFC 9113 https://www.rfc-editor.org/rfc/rfc9113.html#section-5.1.1 > Streams are identified by an unsigned 31-bit integer. Streams initiated by > a client MUST use odd-numbered stream identifiers; those initiated by the > server MUST use even-numbered stream identifiers. https://www.rfc-editor.org/rfc/rfc9113.html#section-6.5.2-2.4.1 > <https://www.rfc-editor.org/rfc/rfc9113.html#section-6.5.2-2.4.1>SETTINGS_ENABLE_PUSH > (0x02): > This setting can be used to enable or disable server push. A server MUST > NOT send a PUSH_PROMISE frame if it receives this parameter set to a value > of 0; see Section 8.4. A client that has both set this parameter to 0 and > had it acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a > connection error (Section 5.4.1) of type PROTOCOL_ERROR. > The initial value of SETTINGS_ENABLE_PUSH is 1. For a client, this value > indicates that it is willing to receive PUSH_PROMISE frames. For a server, > this initial value has no effect, and is equivalent to the value 0. Any > value other than 0 or 1 MUST be treated as a connection error (Section > 5.4.1) of type PROTOCOL_ERROR. > A server MUST NOT explicitly set this value to 1. A server MAY choose to > omit this setting when it sends a SETTINGS frame, but if a server does > include a value, it MUST be 0. A client MUST treat receipt of a SETTINGS > frame with SETTINGS_ENABLE_PUSH set to 1 as a connection error (Section > 5.4.1) of type PROTOCOL_ERROR. On Thu, Oct 10, 2024 at 2:11 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Wed, Oct 09, 2024 at 06:29:58PM -0400, Josh Cohen wrote: > > > > The world has evolved, and now with h2/h3, we have the ability for the > > server to initiate and open a stream to the client that has connected to > > the server. If we assume that the client/browser can have a small web > > server engine running, then the Event Channel can just be HTTP requests > > (say using NOTIFY method) sent downstream from the server to the client. > > For HTTP/2, that was one of the things removed in RFC9113 (the original > RFC7540 had that capability). > > For HTTP/3, it would require negotiating an extension. > > > > > -Ilari > > -- --- *Josh Co*hen
Received on Saturday, 12 October 2024 01:46:36 UTC