Changeset 1736 for draft-ietf-httpbis/latest/p7-auth.xml
- Timestamp:
- 08/07/12 12:30:37 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.xml
r1726 r1736 260 260 The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server 261 261 to challenge the authorization of a user agent. This response &MUST; 262 include a WWW-Authenticateheader field containing at least one262 include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one 263 263 challenge applicable to the requested resource. 264 264 </t> 265 265 <t> 266 The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to267 challenge the authorization of a client and &MUST; include a Proxy-Authenticate268 header field containing at least one challenge269 applicable to the proxy for the requested resource.266 The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is 267 used by a proxy to challenge the authorization of a client and &MUST; 268 include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least 269 one challenge applicable to the proxy for the requested resource. 270 270 </t> 271 271 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/> … … 275 275 <t> 276 276 &Note; User agents will need to take special care in parsing the 277 WWW-Authenticate and Proxy-Authenticate header field values because they278 can contain more than one challenge, or if more than one of each is279 provided, since the contents of a challenge can itself contain a280 c omma-separated list of authentication parameters.277 <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref> 278 header field values because they can contain more than one challenge, or 279 if more than one of each is provided, since the contents of a challenge 280 can itself contain a comma-separated list of authentication parameters. 281 281 </t> 282 282 </x:note> … … 291 291 A user agent that wishes to authenticate itself with an origin server 292 292 — usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref> 293 — can do so by including an Authorizationheader field with the293 — can do so by including an <x:ref>Authorization</x:ref> header field with the 294 294 request. 295 295 </t> … … 297 297 A client that wishes to authenticate itself with a proxy — usually, 298 298 but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref> 299 — can do so by including a Proxy-Authorizationheader field with the299 — can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the 300 300 request. 301 301 </t> 302 302 <t> 303 Both the Authorization field value and the Proxy-Authorizationfield value303 Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value 304 304 contain the client's credentials for the realm of the resource being 305 305 requested, based upon a challenge received from the server (possibly at … … 316 316 invalid credentials (e.g., a bad password) or partial credentials (e.g., 317 317 when the authentication scheme requires more than one round trip), an origin 318 server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST; 319 include a WWW-Authenticate header field containing at least one (possibly 320 new) challenge applicable to the requested resource. 318 server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such 319 responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field 320 containing at least one (possibly new) challenge applicable to the 321 requested resource. 321 322 </t> 322 323 <t> … … 324 325 credentials or contain invalid or partial credentials, a proxy &SHOULD; 325 326 return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses 326 &MUST; include a Proxy-Authenticate headerfield containing a (possibly327 &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly 327 328 new) challenge applicable to the proxy. 328 329 </t> … … 340 341 </t> 341 342 <t> 342 Proxies &MUST; forward the WWW-Authenticate and Authorization headers 343 unmodified and follow the rules found in <xref target="header.authorization"/>. 343 Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and 344 <x:ref>Authorization</x:ref> header fields unmodified and follow the rules 345 found in <xref target="header.authorization"/>. 344 346 </t> 345 347 </section> … … 467 469 <t> 468 470 Authentication schemes need to document whether they are usable in 469 origin-server authentication (i.e., using WWW-Authenticate), and/or470 proxy authentication (i.e., using Proxy-Authenticate).471 origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>), 472 and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>). 471 473 </t> 472 474 </x:lt> 473 475 <x:lt> 474 476 <t> 475 The credentials carried in an Authorizationheader field are specific to477 The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to 476 478 the User Agent, and therefore have the same effect on HTTP caches as the 477 479 "private" Cache-Control response directive, within the scope of the … … 480 482 <t> 481 483 Therefore, new authentication schemes which choose not to carry 482 credentials in the Authorization header(e.g., using a newly defined483 header ) will need to explicitly disallow caching, by mandating the use of484 credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined 485 header field) will need to explicitly disallow caching, by mandating the use of 484 486 either Cache-Control request directives (e.g., "no-store") or response 485 487 directives (e.g., "private"). … … 501 503 <t> 502 504 The request requires user authentication. The response &MUST; include a 503 WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge504 applicable to the target resource. The client &MAY; repeat the505 re quest with a suitable Authorization header field (<xref target="header.authorization"/>). If506 the request already included Authorization credentials, then the 401507 response indicates that authorization has been refused for those508 credentials. If the 401 response contains the same challenge as the509 prior response, and the user agent has already attempted505 <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>) 506 containing a challenge applicable to the target resource. The client &MAY; 507 repeat the request with a suitable <x:ref>Authorization</x:ref> header field 508 (<xref target="header.authorization"/>). If the request already included 509 Authorization credentials, then the 401 response indicates that authorization 510 has been refused for those credentials. If the 401 response contains the 511 same challenge as the prior response, and the user agent has already attempted 510 512 authentication at least once, then the user &SHOULD; be presented the 511 513 representation that was given in the response, since that representation might … … 520 522 This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the 521 523 client ought to first authenticate itself with the proxy. The proxy &MUST; 522 return a Proxy-Authenticateheader field (<xref target="header.proxy-authenticate"/>) containing a524 return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a 523 525 challenge applicable to the proxy for the target resource. The 524 client &MAY; repeat the request with a suitable Proxy-Authorization526 client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref> 525 527 header field (<xref target="header.proxy-authorization"/>). 526 528 </t> … … 601 603 </artwork></figure> 602 604 <t> 603 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to604 the current connection, and intermediaries &SHOULD-NOT; forward it to605 downstream clients. However, an intermediate proxy might need to obtain its606 own credentials by requesting them from the downstream client, which in607 some circumstances will appear as if the proxy is forwarding the605 Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field 606 applies only to the current connection, and intermediaries &SHOULD-NOT; 607 forward it to downstream clients. However, an intermediate proxy might need 608 to obtain its own credentials by requesting them from the downstream client, 609 which in some circumstances will appear as if the proxy is forwarding the 608 610 Proxy-Authenticate header field. 609 611 </t> 610 612 <t> 611 Note that the parsing considerations for WWW-Authenticate apply to this612 header field as well; see <xref target="header.www-authenticate"/> for613 details.613 Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref> 614 apply to this header field as well; see <xref target="header.www-authenticate"/> 615 for details. 614 616 </t> 615 617 </section> … … 630 632 </artwork></figure> 631 633 <t> 632 Unlike Authorization, the Proxy-Authorization header field applies only to633 the next outbound proxy that demanded authentication using the Proxy-Authenticate634 Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field applies only to 635 the next outbound proxy that demanded authentication using the <x:ref>Proxy-Authenticate</x:ref> 634 636 field. When multiple proxies are used in a chain, the 635 637 Proxy-Authorization header field is consumed by the first outbound … … 828 830 Possible mitigation strategies include restricting direct access to 829 831 authentication credentials (i.e., not making the content of the 830 Authorizationrequest header field available), and separating protection832 <x:ref>Authorization</x:ref> request header field available), and separating protection 831 833 spaces by using a different host name for each party. 832 834 </t>
Note: See TracChangeset
for help on using the changeset viewer.