http-extensions
http-extensions copied to clipboard
httpwg
Alt-Svc and ORIGIN
We should find space to discuss the implications of ORIGIN as it relates to Alt-Svc usage. Basic idea: an alternative service fails for an origin if ORIGIN frames are received that do not list that origin.
I'm not quite sure I understand the implication here. I thought that by definition an alternative was authoritative for the origin (assuming the connection is correctly authenticated). Is that idea that a server could send an ORIGIN frame in such a way that it exclude the original origin? I thought 421 was for this use case, and ORIGIN was for addressing connection coalescing? But maybe I'm misunderstanding the proposal?
So my understanding of the positioning of ORIGIN and 421 is that 421 is reactive (you only send it in response to a request), whereas ORIGIN is proactive (you send it to pre-empt potentially unwanted requests). Overall, the two are intended to be complementary.
The goal here would only be to acknowledge the role that ORIGIN plays.
I think I must be misunderstanding RFC 8336. I thought it was specifically to add additional origins in additional to the initial origin. Specifically this text:
When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain an initial origin.
... The contents of that ORIGIN frame (and subsequent ones) allow the server to incrementally add new origins to the Origin Set, as described in Section 2.2.
As I read that, there is no mechanism for the ORIGIN frame to remove origins, only to add them. How does the ORIGIN frame cause origins to be removed from the Origin Set?
The introduction says it fairly clearly: clients might coalesce origins onto a connection based on the certificate. A certificate, particularly one with a bunch of wildcards (*.example.com) can be rather permissive. ORIGIN allows a server to say which specific domains are active.
For instance, you connect to www.example.com and it has a certificate for *.example.com. You might at that point coalesce assets.example.com onto that connection, not knowing if the server supports ORIGIN. If the server sent ORIGIN(www.example.com) then you would not coalesce any other names unless the server subsequently sends more ORIGIN frames, at which point you can send requests for any origin thus added.
The removal of origins therefore occurs implicitly along with the first ORIGIN frame.
Since this issue was discussing alt-svc, I thought the concern was the ORIGIN frame making the connection no longer valid for the origin that it was initially established for (which the ORIGIN frame is unable to do). But I think you're saying the the concern is what happens when a connection to an alternative service (origin A) is coalesced onto an existing connection (to origin B) which had a cert valid for multiple origins (A & B) but the ORIGIN frame removes origin A. Is that the concern this issue describes?
Yes. Say you get alt-svc for example.com that refers to cdn.example. You already have a connection active to cdn.example (maybe with some other target name) and the IP address matches (if you care about that). Receiving an ORIGIN frame that did not include example.com would mean that THAT alternative cannot be used and a fresh connection might be needed.
Interesting! Thanks for the example. In your example when you say, "a connection active to cdn.example.com" that's not sufficient to allow that connection to be used for a request to "example.com", right? You would further need the cert (or ORIGIN frames) to be valid for that as well. But once you have a connection (which was initially established to any host, whether it was the alt-svc host or not) the fact that the connection is authoritative for the origin means that it may be used for requests to that origin. Does alt-svc come into play at all here? It seems like the thing that will fail here is not alt-svc but rather coalescing?
Maybe I'm just thinking about this in the context of how alt-svc support is implemented in Chrome. Basically, the only time the alt-svc information is considered is when establishing a new connection. Once the connection is established, it is put into a map in which the key is the initial origin (and other origins covered by the cert) and is then eligible for future request to that origin. So in this way, the ORIGIN frame won't 'cause alt-svc to fail, it will cause coalescing to fail. But am I thinking about this in a way that is clouding the picture? Maybe a different implementation would surface alt-svc in a different way.
Let's say that the cdn.example connection was originally established to a different host. Then example.com advertises uses the IP address of cdn.example in Alt-Svc. This IP address does not appear in A/AAAA records for example.com, so the client would never have attempted to use that connection, even though the offered certificate lists example.com. However, once Alt-Svc points to that IP address, it can then use that connection for example.com.
The Alt-Svc spec isn't very clear about whether coalescing can be used. This is also a part of fetch that isn't well mapped out. I model this process as "obtain a connection to the origin" rather than "establish a connection to the origin". In that framing, using an existing connection is a perfectly valid choice.
If you only ever use Alt-Svc for the purposes of creating connections (and not reusing them), then ORIGIN can't disqualify a conneciton.
I've opened #1696 to track what is probably a bigger issue. We might want to fix these two issues with the same text.
@RyanTheOptimist, there are two directions ORIGIN can go. The one originally contemplated in the spec is that ORIGIN will specify a tighter set of origins than the cert presented on the connection would suggest; the server is able to prevent requests that the client might otherwise make.
In the now-dead Secondary Certs draft, a second use for ORIGIN was proposed -- the server could also indicate additional origins not on the primary cert, and the client could ask to see the appropriate certs if interested. However, with that draft gone, ORIGIN is back to only restricting, not expanding, the set of possible origins. If the server indicates origins not on the certificate, the client will consider the connection not authoritative for those names and not make requests (or accept pushes) for them.
