Per-hop behaviour of Subscribe requests

[alficles]

I don't believe the currently described subscription routine will work properly when an unaware proxy lies between the origin and the client. The client can send a request to the proxy, which will forward the Subscribe header unaware of its meaning. The origin will then keep the connection open to the proxy indefinitely, which the proxy is definitely not prepared for. Most likely, the proxy will time out the connection and the client will get an error.

I don't see a way to do the Subscribe header that isn't per-hop. As a per-hop header, it would need to be included in the Connection header for HTTP/1 and be handled as a new SETTING in HTTP/2 and /3.

[toomim]

Wow, I am so grateful to hear this! I had not thought about that. Thank you for coming and applying your mind to this problem! We don't have anyone else experienced with proxies in the group, yet, and I can see that you've got a lot you can contribute.

So yes, I think you're right. I wasn't even aware of the Connection header or SETTING spec. I will do some research.

Thank you!

[alficles]

And I'll have to admit, I'm not the most experienced HTTP/2 expert out there. We're going to need to think carefully about the implementation in H/2. All connection-related headers have been removed from the request and moved into settings and frames. This means that a connection-related thing affects all requests on the same connection. So if you wanted to make a "Subscribe" request for a large object (say, an ever-updating-SVG-animation) and specifically not subscribe to another large object (say, a live video file being updated via append), we'll need to think carefully about how we allow the client to express that preference. Or perhaps declare that out of scope and say the client can use multiple connections if they need to.

[toomim]

Interesting. So on the one-hand, it seems that the Subscribe: header should be per-hop, so that any two client/server/proxies that support it can benefit, even if the whole chain doesn't. This makes it sound like it should be a connection header, instead of a request header, because (if I'm understanding correctly) a connection header is per-hop, but a request header applies to the entire chain of client/proxies/servers.

But on the other hand, the Subscribe: header should be a request header, because the client might want to hold a subscription to it in one request, while simultaneously asking for a single version in a different request.

[alficles]

What if we used a subscription frame in H/2+? We could define a new frame type (unaware implementations MUST ignore) and use that for subscription. Then, it would be completely separate from any actual requests. If you want an actual object you can request it. Your subscription frame would then contain the headers necessary for setting up the subscription. You can look at the PUSH_PROMISE frame for an example in the opposite direction.

In H/1, we just have to add Subscribe to the Connection header. The delineation between requests and connections is kinda loose in H/1 anyway. The only thing the Connection header does in H/1 is prevent intermediaries from forwarding the connection.