#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 10 years ago by fielding@…
comment:2 Changed 10 years ago by fielding@…
- Milestone changed from unassigned to 23
- Resolution set to incorporated
- Status changed from new to closed
From [2279]:
add optional fragment to the URI definitions, as required by RFC3986; addresses #451