Skip to main content

The Proxy-Status HTTP Response Header Field
draft-ietf-httpbis-proxy-status-08

Yes

Francesca Palombini

No Objection

(Alvaro Retana)
(Martin Vigoureux)
(Robert Wilton)

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

Erik Kline
Yes
Comment (2021-08-21 for -06) Sent
[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
Murray Kucherawy
No Objection
Comment (2021-08-25 for -06) Sent
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"?
Roman Danyliw
No Objection
Comment (2021-08-23 for -06) Not sent
Thank you to Rich Salz for the SECDIR review.

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

Section 2.1.3

  https://www.iana.org/assignments/tls-extensiontype-values/tls-
   extensiontype-values.xhtml#alpn-protocol-ids
   (https://www.iana.org/assignments/tls-extensiontype-values/tls-
   extensiontype-values.xhtml#alpn-protocol-ids)).  

Section 2.2.
   See the registry at https://iana.org/assignments/http-proxy-status
(https://iana.org/assignments/http-proxy-status)
Warren Kumari
No Objection
Comment (2021-08-25 for -06) Sent
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) Not sent
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) Sent
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 https://datatracker.ietf.org/doc/review-ietf-httpbis-proxy-status-06-intdir-telechat-overeinder-2021-08-24/

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,

Regards,

-éric

== COMMENTS ==

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' ?
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-10-12 for -07) Sent
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 Former IESG member
No Objection
No Objection (2021-08-24 for -06) Sent
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
order?

-------------------------------------------------------------------------------
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 https://github.com/larseggert/ietf-reviewtool), 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 Former IESG member
No Objection
No Objection (2021-08-20 for -06) Sent
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 Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (for -06) Not sent