lukasa/http2-p2p

A source code repository for the P2P extension for HTTP/2

http2-p2p's Issues

Better attribution

From the mailing list:

Not to toot our own vuvuzela, but i think David Dias and I [Juan Benet] helped
originate this idea :) -- this whole story began with our asking
Fedor to implement this in his spdy/http2 node module, as some Go
implementations of SPDY function in a similar way.

Explicitly identify which peer uses which kind of stream ID

From the mailing list:

streams with PUSH_PROMISE and also lifts some of the restrictions of
RFC 7540 [RFC7540] Section 8: specifically those sections that only
allow servers to send PUSH_PROMISE frames, and only allow clients to
receive them.

If the client attempts to send a PUSH_PROMISE frame on a stream that
was opened by the client (by sending a HEADERS frame), the server
MUST treat this event as a connection error ([RFC7540] Section 5.4.1)
of type PROTOCOL_ERROR.

2.6. Other Extensions

When this extension is deployed with other extensions to HTTP/2, the
behaviour of this extension does not change. All other extensions
that refer to 'client' or 'server' SHOULD be treated as though those
terms apply on a per-stream basis.

If other extensions apply 'server' or 'client' to the whole
connection (e.g. for settings in SETTINGS frames, which are sent on
stream 0), then both peers SHOULD be considered clients and both
peers should be considered servers.

Ok i worry about this wording because there are a few things in the HTTP2
spec that are mant to be done by a client or server merely to coordinate,
like numbering the streams even and odd. Which number would a peer pick,
if they're considered the same? This seems like a spec bug to me, as I
think it is unclear how to pick stream ids now. (maybe i'm missing
something). I suspect there may be other such ambiguities.

Elaborate on the interaction between SETTINGS_PEER_TO_PEER and SETTINGS_ENABLE_PUSH

From the mailing list:

If the client, subsequent to sending SETTINGS_PEER_TO_PEER with value
1, receives from the server a value of SETTINGS_ENABLE_PUSH of 1, it
MAY open streams by sending PUSH_PROMISE frames. The client MUST NOT
send a PUSH_PROMISE frame on a stream that it opened by means of a
HEADERS frame: only server-initiated streams may be used for sending
PUSH_PROMISE frames. All other limitations about PUSH_PROMISE frames
in RFC 7540 [RFC7540] continue to apply, except that the words
'server' and 'client' are defined on a per-stream basis.

2.5. Server Behavioral Changes

When a server receives the SETTINGS_PEER_TO_PEER setting from the
client with a value of 1, it MAY at any point afterwards issue a non-
zero value for SETTINGS_ENABLE_PUSH. This allows clients to open

It took me a while to grasp the relationship between these two settings.
Perhaps it may be useful to motivate the need for SETTINGS_ENABLE_PUSH
from server to client, and why it's not needed client to server (namely,
in client-to-server, it begins enabled, and is turned off. in server-to-
client, it begins off, and is turned on. -- if i'm wrong about this,
then that's more evidence this is a bit convfusing :/ ).

Consider removing the ability to send multiple CLIENT_AUTHORITY frames.

From the mailing list:

2.2.2. Semantics

Generally speaking, a server or coalescing intermediary has no in-
band method of validating that a client's authority claims are valid.
Therefore, a conforming server MUST confirm a client's authority
claims using some out-of-band method: see Section 3 for more.

A client MAY send a CLIENT_AUTHORITY frame at any time after the
HTTP/2 preamble is complete. Each CLIENT_AUTHORITY frame is
considered to be a complete list of authorities: therefore, a server
MUST disregard all prior CLIENT_AUTHORITY frames when a new one is
received. Also, servers MUST validate the asserted authorities for
all CLIENT_AUTHORITY frames, not just the first one.

Oh interesting, so the authority may change during the connection? It may
be useful to point to why this is useful, linking to the HTTP2 spec or
elsewhere.

I have very mixed feelings about this: we should consider removing it.