Ticket #295 (closed design: fixed)
Applying original fragment to "plain" redirected URI
|Reported by:||email@example.com||Owned by:||firstname.lastname@example.org|
|Component:||p2-semantics||Severity:||Active WG Document|
In the resolution to #43, we warned that we don't define precedence when both the request URI and the redirected URI have fragment identifiers;
Note: This specification does not define precedence rules for the case where the original URI, as navigated to by the user agent, and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might inconvenience anyone relying on the semantics of the original URI's fragment identifier.
However, we didn't explicitly cover the case where the request-URI has a fragment identifier, but the Location URI does not.
This should be defined; at a minimum, we should say that we don't specify behaviour, to warn people of interop problems.
Interestingly, an old I-D did specify behaviour here:
If the server returns a response code of 300 ("multiple choice"), 301 ("moved permanently"), 302 ("moved temporarily") or 303 ("see other"), and if the server also returns one or more URIs where the resource can be found, then the client SHOULD treat the new URIs as if the fragment identifier of the original URI was added at the end.
Test script at:
tests T4 and T8 (note that the "FAIL/PASS" determinations assume that the resolution would align with draft-bos-http-redirect).
- Owner changed from email@example.com to firstname.lastname@example.org
comment:10 Changed 4 years ago by email@example.com
- Status changed from new to closed
- Resolution set to incorporated
comment:11 Changed 3 years ago by firstname.lastname@example.org
- Status changed from closed to reopened
- Resolution incorporated deleted