The Proxy-Status HTTP Response Header Field

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline Yes

Comment (2021-08-21 for -06)
[S2.1.2, question]

* Can a port number also be expressed in this parameter (e.g., in the event
  that non-standard port numbers are configured)?

Francesca Palombini Yes

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2021-10-12 for -07)
Thank you for the updates in the -07; they look good.

Two remarks on the new content in the -07:

In Section 2.1.1 the prose accompanying the example that uses
a 429 response code mentions "the reverse proxy", but the
Proxy-Status list members in the example have been changed to
no longer mention "SomeReverseProxy" in favor of an example hostname
specific to a given deployment.

The template for the proxy error types registry (Section 2.4), as
well as the initial registry contents in Sections 2.3.x, use the
phrase "Only generated by intermediaries".  My apologies if I made
this comment already and it was discarded, but that phrasing is
easy to misread as saying that the *error* was only generated by
intermediaries, when the intent is that the (possibly partial)
response content was only generated by intermediaries.  So I'd consider
adding "response", for "Response only generated by intermediaries"
(or similar) to forestall such confusion.

Lars Eggert No Objection

Comment (2021-08-24 for -06)
Section 2. , paragraph 12, comment:
>    When adding a value to the Proxy-Status field, intermediaries SHOULD
>    preserve the existing members of the field, to allow debugging of the
>    entire chain of intermediaries handling the request.

I'm surprised this is not a MUST? Are there any valid reasons for not observing

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 2, nit:
> e critical infrastructure of many Web sites. Typically, HTTP intermediaries
>                                   ^^^^^^^^^
Nowadays, it's more common to write this as one word.

Section 2.1.1. , paragraph 6, nit:
> ed HTTP Status Code. When generating a HTTP response containing "error", its
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour". (Also elsewhere.)

Section 2.1.2. , paragraph 1, nit:
>  protocol identifier is able to be expressed as an sf-token using ASCII encod
>                                 ^^^^^^^^^^^^
Avoid the passive voice after "to be able to".

Martin Duke No Objection

Comment (2021-08-20 for -06)
I'm disappointed that there isn't an end-to-end connection option to request this field. It would be a useful mode for intermediaries to only include this field on request for performance reasons (as IIUC this is mainly about debugging).

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2021-08-25 for -06)
Nice work, as usual for this WG.

Question 7 (an important one) in the shepherd writeup has not been properly answered.

I had the same thought as Warren about seeing an example of multiple proxies being indicated, which in turn might report details.  I think I saw that there's a proposal for one to be included, so I'll go check that out.

Section 2:

* "... or when the request contains a header that activates a debugging mode." -- should that be "header field"?

Robert Wilton No Objection

Roman Danyliw No Objection

Comment (2021-08-23 for -06)
No email
send info
Thank you to Rich Salz for the SECDIR review.

-- Editorial.  These inline URLs are being rendered as “URL (URL)”.

Section 2.1.3

Section 2.2.
   See the registry at

Warren Kumari No Objection

Comment (2021-08-25 for -06)
This was a good, and very readable document. Thank you!

I'd *really* like to see an example showing a header with both multiple proxies *and* a message/error, something like: Proxy-Status: FooProxy, SomeCDN; error=connection_timeout
This will, I hope, reduce the chance of someone messing up and assuming either just multiple proxies *or* more info.

It seems like just extending the example in 2.1.1 (or adding a second example to that section) should be easy...

Zaheduzzaman Sarker No Objection

Comment (2021-08-25 for -06)
No email
send info
Thanks for the efforts on this document. Thanks to Magnus Westerlund for his TSVart review.

Éric Vyncke No Objection

Comment (2021-08-25 for -06)
Thank you for the work put into this document. This header could indeed be very useful for debugging !

Please find below  some non-blocking COMMENT points (but replies would be appreciated).

Please also address Benno Overeinder's INTDR review at

Special thanks to Tommy Pauly for his shepherd's write-up notably about the WG consensus.

I hope that this helps to improve the document,




Is there any reason why a 'Proxy-Status-Request' (or similar) is not specified ?

-- Section 2 --
About "Origin servers MUST NOT generate the Proxy-Status field.", while I understand the reasoning of it, I still wonder how a 'smart gateway' (not a plain HTTP proxy but more like a content changer, such as mobile optimization by reducing IMG size, or language translation, or ...) should handle this ? As it is new content, the 'smart gateway' is the origin but getting info from the real origin could also be useful. Or is it simply over-complex ?

-- Section 2.1.2 --
Some explanations about the example would be welcome.

-- Section 2.3 --
Should there be an error type for 'too many intermediaries' ?