Re: Proposal: Adopt State Synchronization into HTTPbis

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