- From: Martin Thomson <mt@lowentropy.net>
- Date: Wed, 16 Oct 2024 14:09:36 +1100
- To: "Lucas Pardue" <lucas@lucaspardue.com>, "Kazuho Oku" <kazuhooku@gmail.com>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>, "Tommy Pauly" <tpauly@apple.com>
On Wed, Oct 16, 2024, at 13:29, Lucas Pardue wrote: [...] >> Maybe the right thing to do is allow two values to be set in the Incremental header: >> * "Incremental: required" should be used by applications that prefer to see errors when intermediaries cannot provide incremental delivery. >> * "Incremental: preferred" should be used by applications that would benefit from incremental delivery but can operate without. [...] > Yeah that's where I was headed in my head. But I think that only > addresses one direction, where a client wants its request body to be > forwarded incrementally. > > If a server needs its response body forwarded incrementally (and I'm > aware of cases this is true), it can't be sure if the proxy would do > that. So I was wondering if something like an "incremental-allowed: > bool" request header could be defined that a proxy could send when it > makes its policy decision. That way, an origin might stand a better > chance of detecting a problem directly at source. Especially in a > deployment where the proxy and origin have tighter integration > expectations but worse logging cohesion. Interesting discussion. This suggests that maybe we have a different solution in front of us: https://datatracker.ietf.org/doc/html/rfc7240#section-3 Request -> Prefer: incr Response -> Preference-Applied: incr It's not perfect in that this was designed to be a response field generated by the resource, not an intermediary, but it seems pretty consistent with the use case. (For OHTTP at least, the relay is the resource, even if there is an expectation that the request is forwarded onwards.)
Received on Wednesday, 16 October 2024 03:10:01 UTC