Visual RFC.
ALL RFCs / RFC 7617
Read the RFC ↗
RFC 7617 / HTTP BASIC AUTHENTICATION

Reuse credentials within the inferred scope

04

After a successful authenticated request, a client can infer where the same credentials might apply and optionally send them before another challenge.

DIAGRAMRead RFC section 2.2 ↗
RFC 7617 · § 2.2EXAMPLE
3 / 3
Reuse credentials within the inferred scopeAn authenticated HTTPS URI is reduced to its enclosing /docs/ path scope. A client may preemptively reuse credentials for a matching resource, but this is optional, not an access grant. Other paths, schemes and authorities are outside that inferred scope; a failed reuse inference stops before sending credentials.Infer a scope, do not widen it silentlyAuthenticated: https://example.com/docs/index.html/other/ different pathhttp://example.com/docs/ different schemehttps://other.example/docs/ different hostKnown credentialOther locationno inferred reuseNo credentials sent by this failed inferenceOverlapping scopes: no priority rule defined here
03
Reject the inference for other locations.

/other/ fails the path-prefix test; http://example.com/docs/ changes scheme; https://other.example/docs/ changes authority. None is justified by this scope inference. Use a separate authentication decision.

Source for this drawing: RFC 7617 · Read RFC section 2.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 4648 Base encodings RFC 8446 TLS 1.3

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Scope
The inferred set of URIs where these credentials may apply.
Preemptive
Sending known credentials without waiting for another challenge.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Derive scope from the absolute authenticated URI by removing everything after the last slash of its path component.

  • Derive scope from the absolute authenticated URI by removing everything after the last slash of its path component.
  • A client SHOULD assume resources with a prefix match of that scope are in the same protection space. It MAY preemptively send the corresponding Authorization field there.
  • A different path prefix or scheme falls outside that inferred scope. The realm name does not authorize copying credentials to arbitrary hosts.
  • Overlapping authentication scopes can occur. RFC 7617 does not define which scope has higher priority. This is credential reuse guidance, not an access-control guarantee.
DETAILS

The drawing uses a secure variation of §2.2’s example: https://example.com/docs/index.html yields https://example.com/docs/. The query in /docs/?page=1 does not change the path prefix. /other/, a different hostname, and an http scheme are not in that inferred scope. No HTTP downgrade is performed: the red line rejects automatic reuse by this inference. A server still validates every authenticated request. A proxy MAY similarly reuse Proxy-Authorization without another challenge.

Read the RFC section ↗

All chapters in RFC 7617

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗