Subject: Call for Adoption: Proxy Status

From: Tommy Pauly <[email-masked]>
Date: Wed, 10 Apr 2019 17:24:35 -0700

Hello HTTPBis,

In our meeting in Prague, we had a presentation of a new document, "The Proxy-Status HTTP Header Field”. There was positive response in the room about adopting this in the working group.

The document can be found here: https://tools.ietf.org/html/draft-nottingham-proxy-status-00 <https://tools.ietf.org/html/draft-nottingham-proxy-status-00>

This email starts a call for adoption. Please reply to this email with your thoughts, and state whether or not you believe the group should adopt this document. Feedback is requested by Wednesday, April 24.

Thanks,
Tommy

---

From: Cory Benfield <[email-masked]>
Date: Thu, 11 Apr 2019 12:11:03 +0100

I'm in favour of adoption of this document: I think this kind of
metadata would be very useful in many organisations.

Cory

On Thu, 11 Apr 2019 at 01:27, Tommy Pauly <[email-masked]> wrote:
> The document can be found here: https://tools.ietf.org/html/draft-nottingham-proxy-status-00
>

---

From: Koshiba Masaori <[email-masked]>
Date: Fri, 12 Apr 2019 10:08:09 +0900

I am in support of adopting this. This looks useful to know what was
happened in (reverse) proxy.

- Masaori

On Thu, Apr 11, 2019 at 8:15 PM Cory Benfield <[email-masked]> wrote:

> > In our meeting in Prague, we had a presentation of a new document, "The
> Proxy-Status HTTP Header Field”. There was positive response in the room
> about adopting this in the working group.
> >
> > The document can be found here:
> https://tools.ietf.org/html/draft-nottingham-proxy-status-00
> >
> > This email starts a call for adoption. Please reply to this email with
> your thoughts, and state whether or not you believe the group should adopt
> this document. Feedback is requested by Wednesday, April 24.
> >
> > Thanks,
> > Tommy
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 12 Apr 2019 09:33:32 +0000

--------
In message <[email-masked]>, Tommy Pauly writes:

>your thoughts, and state whether or not you believe the group should 
>adopt this document. Feedback is requested by Wednesday, April 24.

I think we should adopt it, a common vocabulary is always a good thing.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Leif Hedstrom <[email-masked]>
Date: Thu, 11 Apr 2019 22:45:17 -0700

> On Apr 10, 2019, at 17:24, Tommy Pauly <[email-masked]> wrote:
> 
> Hello HTTPBis,
> 

Yeh, we should adopt this. I will probe our developer community for input and interest next week, but I’m pretty confident we would implement this in ATS.

— Leif

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 13 Apr 2019 21:42:10 +1200

I'm in favour of adopting. Replacing the X-* headers currently used with
a standard mechanism is a nice improvement.

Amos

On 11/04/19 12:24 pm, Tommy Pauly wrote:
> adopt this document. Feedback is requested by *Wednesday, April 24*.
> 
> Thanks,
> Tommy

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 21 Apr 2019 10:50:19 -0600

> adopt this document. Feedback is requested by *Wednesday, April 24*.

I believe the scope of the document should be enlarged from the current
"error details in the proxy-generated response" to something like "proxy
status(es) when handling the message". After that, it should be adopted.

IMHO, there is no good reason to restrict a generic "Proxy-Status"
mechanism to proxy-generated errors, especially since existing proxies
already use similar mechanisms to relay their state when forwarding
messages (in addition to generating error responses). Typical uses
include relaying caching state (initial lookup outcome, refresh
activity, etc.) and proxy-specific transaction IDs (for correlating
messages with proxy logs).

Thank you,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2019 10:34:42 +1000

> On 22 Apr 2019, at 2:50 am, Alex Rousskov <[email-masked]> wrote:
> 

Hi Alex,

Agreed; Piotr and I have already been discussing that. That said, we should be careful to understand the delineation between this and the Cache header.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 22 Apr 2019 21:06:37 -0600

On 4/22/19 6:34 PM, Mark Nottingham wrote:
>> On 22 Apr 2019, at 2:50 am, Alex Rousskov wrote:

> Agreed; Piotr and I have already been discussing that. That said, we
> should be careful to understand the delineation between this and the
> Cache header.

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. The
"universal" header must have a list syntax, but that syntax is required
for each of the two header fields anyway.

If the Cache header has already been standardized, this draft can
deprecate its early limited usage in favor of a "universal" Proxy-Status.

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2019 15:38:34 +1000

Hi Alex,

> On 23 Apr 2019, at 1:06 pm, Alex Rousskov <[email-masked]> wrote:
> 

I disagree pretty strongly; caches can occur within the origin server (and one of the implementers interested in cache is doing exactly that), and caching semantics are detailed enough that they deserve separate attention and communication. 

Besides, we're trying to pave cowpaths here; Cache follows X-Cache, and this header is trying to align a variety of other behaviours. Let's not get too ambitious.

Cheers,

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 23 Apr 2019 10:24:47 -0600

On 4/22/19 11:38 PM, Mark Nottingham wrote:
>> On 23 Apr 2019, at 1:06 pm, Alex Rousskov wrote:
>> 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.

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 28 Apr 2019 14:58:02 -0700

The period for adoption input has passed; we've gotten a good amount of positive feedback, with some comments about changes to make in future versions. Thanks for everyone's input!

Authors, please submit a revision as a WG draft when ready.

Best,
Tommy

> On Apr 10, 2019, at 5:24 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello HTTPBis,
>