Changeset 2558

Timestamp:

18/01/14 06:22:49 (7 years ago)

Author:

fielding@…

Message:

(editorial) rephrase the description of proxy chaining in Proxy-Authenticate; see #522 and #536

Location:

draft-ietf-httpbis/latest

Files:

• p7-auth.html (modified) (1 diff)
• p7-auth.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p7-auth.html

@@ -760 +760 @@
             <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
             <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
-               applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response.
+               applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). A proxy <em class="bcp14">MUST</em> send at least one Proxy-Authenticate header field in each <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that it generates.
             </p>
             <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
-</pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the next outbound client on the response chain that chose to direct
-               its request to the responding proxy. If that recipient is also a proxy, it will generally consume the Proxy-Authenticate header
-               field (and generate an appropriate <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> in a subsequent request) rather than forward the header field to its own outbound clients. However, if a recipient proxy needs
-               to obtain its own credentials by requesting them from a further outbound client, it will generate its own 407 response, and
-               this might have the appearance of forwarding the Proxy-Authenticate header field if both proxies use the same challenge set.
+</pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only
+               the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple
+               proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate
+               network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence,
+               in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same
+               challenge set.
             </p>
             <p id="rfc.section.4.2.p.4">Note that the parsing considerations for <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section&nbsp;4.4</a> for details.

draft-ietf-httpbis/latest/p7-auth.xml

@@ -386 +386 @@
    The "Proxy-Authenticate" header field consists of at least one
    challenge that indicates the authentication scheme(s) and parameters
-   applicable to the proxy for this effective request URI (&effective-request-uri;).
-   It &MUST; be included as part of a <x:ref>407 (Proxy Authentication Required)</x:ref> response.
+   applicable to the proxy for this effective request URI
+   (&effective-request-uri;).
+   A proxy &MUST; send at least one Proxy-Authenticate header field in
+   each <x:ref>407 (Proxy Authentication Required)</x:ref> response that it
+   generates.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
@@ -394 +397 @@
 <t>
    Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
-   applies only to the next outbound client on the response chain that chose
-   to direct its request to the responding proxy. If that recipient is also a
-   proxy, it will generally consume the Proxy-Authenticate header field (and
-   generate an appropriate <x:ref>Proxy-Authorization</x:ref> in a subsequent
-   request) rather than forward the header field to its own outbound clients.
-   However, if a recipient proxy needs to obtain its own credentials by
-   requesting them from a further outbound client, it will generate its own
-   407 response, and this might have the appearance of forwarding the
-   Proxy-Authenticate header field if both proxies use the same challenge set.
+   applies only to the next outbound client on the response chain.
+   This is because only the client that chose a given proxy is likely to have
+   the credentials necessary for authentication.  However, when multiple
+   proxies are used within the same administrative domain, such as office and
+   regional caching proxies within a large corporate network, it is common
+   for credentials to be generated by the user agent and passed through the
+   hierarchy until consumed.  Hence, in such a configuration, it will appear
+   as if Proxy-Authenticate is being forwarded because each proxy will send
+   the same challenge set.
 </t>
 <t>