Negotiation algorithm is not ideal about ift HOT 6 CLOSED

Thanks, I'm not too familiar with ALPS, so I'll review that and see if it looks like a better fit for doing the negotiation. It would be great if we could avoid sending the uneeded PatchRequest to a range request only server (so long as we're not adding any extra round trips to do so).

from ift.

I've reviewed ALPS and I have a couple concerns:

1. Since ALPS is part of TLS it works at the connection level. Connections are made to a specific domain and under that domain there may be more than one actual servers processing requests depending on the specific patch requested. Having a frame in ALPS that opts in to patch subset would opt int all paths under that domain, which in many cases may not be ideal (eg. a CDN which serves assets for many different users from the same domain).
2. Using ALPS could complicate implementations where SSL termination is not happening at the same place where the HTTP request is being processed. Again thinking of the example where SSL termination is happening at a single place for a domain but specific paths under that domain are served by completely different servers.

I think then if we want to go down this path, we should make the use of a SETTING via ALPS optional. That is, define a server sent SETTING which instructs the client to only use range request. If the client does not receive that setting it will use the currently specified behaviour of including the PatchRequest message in the first request + fallback to range request depending on the server's response. If it does receive the setting then the client would omit the PatchRequest message from the first request. This then gives a mechanism to servers that don't support patch subset to have clients avoid sending them an unnecessary PatchRequest.

The good news is it looks like we are free define a custom setting identifier under HTTP3 (https://www.rfc-editor.org/rfc/rfc9114.html#name-defined-settings-parameters) as an extension.

@litherum do you have any thoughts?

from ift.

1. a CDN which serves assets for many different users from the same domain

I wouldn't expect CDNs to opt-into patch processing unless they are planning to actually process patches on behalf of their customers. (which AFAIU, they could)

I think then if we want to go down this path, we should make the use of a SETTING via ALPS optional

Adding ALPS as an optional optimization makes sense, where an explicit value from the server opts-in the client to either range-requests or patches, and lack of explicit setting falls back to the currently defined negotiation scheme.

from ift.

Should be fixed by #113. Please reopen if you still have concerns with the new method negotiation introduced by that PR.

from ift.

I think that a CSS based selection may be less aligned with the server's capabilities, but at the same time, it's better than the previous method. May be interesting to keep in mind the possibility of a lower-level negotiation protocol as a future extension.

from ift.

Completely agreed.

from ift.