Re: Call for Adoption: Proxy Status

On 4/22/19 11:38 PM, Mark Nottingham wrote:
>> On 23 Apr 2019, at 1:06 pm, Alex Rousskov wrote:
>> I doubt we need two header fields sharing the same goal of reporting
>> what happened at the proxy. One status header field is enough AFAICT.
>> Any caching-related statuses are a subset of proxy statuses.


> I disagree pretty strongly; caches can occur within the origin server
> (and one of the implementers interested in cache is doing exactly
> that),

If you want to support origin servers, drop or change the Proxy- prefix.
I agree that allowing origin servers (and user agents) to report message
processing/generation details is a good idea.


> and caching semantics are detailed enough that they deserve separate
> attention and communication.

The amount of details in caching semantics does not (or should not)
affect the delivery mechanism/interface IMO. If done right, all those
details are still going to be communicated via a list of "statuses" with
status-specific parameters.

We can, of course, describe caching statuses in a separate draft/RFC,
but there is no benefit (and there is quite a bit of harm!) in spreading
these "statuses" across multiple headers (e.g., Proxy-Status,
Origin-Status, Client-Status, Cache[-Status], Adaptation-Status,
Legal-Status, Storage-Status, CDN-Status, etc., etc.).


> Besides, we're trying to pave cowpaths here; Cache follows X-Cache,
> and this header is trying to align a variety of other behaviours.

Ordering those cows by departure time is very important here.
Reconstructing that order by observing multiple cow paths (without a
single reliable source of cow branding) is often very difficult. A
single cow path gives you that order.

If you insist on having two overlapping headers, I suspect that any
decent caching proxy implementation would _duplicate_ Cache entries in
its Proxy-Status headers...


> Let's not get too ambitious.

The suggested changes would simply remove artificial/unnatural scope
restrictions on the new header. There is nothing ambitious about that!
There is naturally strong consensus that reporting message processing
details is useful. The Proxy-Status draft already defines the framework
for such reporting. It does not need to do anything else to
significantly improve support for many reporting use cases, even if
those use cases are not explicitly enumerated/detailed in the draft
itself. Just removing unnecessary scope restrictions (and possibly
adjusting the header name) is enough.


Cheers,

Alex.

Received on Tuesday, 23 April 2019 16:25:13 UTC