Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#451 closed editorial (incorporated)

HTTP(S) URIs and fragids

Reported by: mnot@… Owned by: draft-ietf-httpbis-p1-messaging@…
Priority: normal Milestone: 23
Component: p1-messaging Severity: In WG Last Call
Keywords: Cc:

Description

P1 sections 2.7.1 and 2.7.2 define the HTTP and HTTPS URI schemes without fragment identifiers.

While it's true that HTTP sends these URIs without fragids "on the wire" in the request-target, the schemes *do* allow fragids pretty much everywhere else they're used (including some places in HTTP, e.g., the Location header).

Given that this is going to be the definition for these URI schemes, and we already require that the fragid be omitted in the request-target, shouldn't the syntax allow a fragment identifier?

I suspect the right thing to do here is to specify that HTTP(s) URIs use the path-abempty form of the hier-part, give some examples, and leave the rest of the ABNF to RFC3986 (or its successors).

Change History (3)

comment:1 Changed 6 years ago by fielding@…

From [2279]:

add optional fragment to the URI definitions, as required by RFC3986; addresses #451

comment:2 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 23
  • Resolution set to incorporated
  • Status changed from new to closed

comment:3 Changed 6 years ago by julian.reschke@…

From [2318]:

rephrase HEAD response payload header field requirement (see #451)

Note: See TracTickets for help on using tickets.