Re: Proposal: Adopt State Synchronization into HTTPbis

Thank you.  I did some research on the history.  In 2015,  a thread[1]
started by Fedor Indutny, subject "HTTP2 server-side stream creation":

During development of [spdy-transport][0] library for node.js, one
> of the contributors asked about the server-side stream creation in
> HTTP2 protocol.



Obviously, the most straightforward way is to do a PUSH_PROMISE on
> existing client-initiated stream, but it appears to me that the
> server-initiated streams created using HEADERS frame are valid
> too.



Is there any place in spec that prohibits it?


That led to a long discussion and a draft[2][3] submitted by Cory Benfield:

> For those who are interested, I’ve submitted an initial draft for the
> HTTP/2 P2P extension to the IETF data tracker: you can find information
> about that draft below.


Looks like one of the issues was the authority value.  How does the client
advertise the authority it serves content from and how can that be
authenticated by the server (the other side of the h2 connection).

In certain cases, like pubsub, it may not be necessary for clients to have
a unique or authenticated authority.  The clients who need to receive
notifications are those who subscribed to the resource.  If fan out takes
place, then the authority name is really a distributed identifier.

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0006.html
[2] https://datatracker.ietf.org/doc/html/draft-benfield-http2-p2p-02
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0140.html



On Sat, Oct 12, 2024 at 3:09 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Fri, Oct 11, 2024 at 09:46:20PM -0400, Josh Cohen wrote:
> > 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?
>
> RFC9113 section 5.1. Stream States:
>
> idle:
>
> "If this stream is initiated by the server, as described in Section
> 5.1.1, then receiving a HEADERS frame MUST also be treated as a
> connection error (Section 5.4.1) of type PROTOCOL_ERROR."
>
> (Also, the transition list only mentions HEADERS in:
>
> "Sending a HEADERS frame as a client, or receiving a HEADERS frame as a
> server, causes the stream to become 'open'."
>
>
> Whereas the corresponding section in RFC7540 lacks the first text and
> the second text is not directional:
>
> "Sending or receiving a HEADERS frame causes the stream to become
> 'open'."
>
>
>
>
> -Ilari
>
>
>

-- 

---
*Josh Co*hen