Closed mnot closed 4 years ago
@mnot changed milestone from unassigned
to 15
julian.reschke@gmx.de changed owner from draft-ietf-httpbis-p2-semantics@tools.ietf.org
to julian.reschke@gmx.de
julian.reschke@gmx.de changed owner from julian.reschke@gmx.de
to ``
julian.reschke@gmx.de changed milestone from 15
to unassigned
julian.reschke@gmx.de commented:
Now in HMTL5:
@mnot changed owner to mnot@pobox.com
julian.reschke@gmx.de commented:
My tests: http://greenbytes.de/tech/tc/httpredirects/#l-fragments
Proposal: To make this change we could add to:
"The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5)."
saying
"... If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, then the original URI's fragment identifier is added to the final value."
(also add examples)
(and also we would kill http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9).
unassigned
to 19
295.diff
Proposed patch
julian.reschke@gmx.de commented:
From 1536:
Location header field: define header field recombination in presence of fragment identifiers, mention security impact, rephrase main definition (see #295)
incorporated
new
to closed
incorporated
to ``closed
to reopened
fixed
reopened
to closed
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;
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: http://tools.ietf.org/html/draft-bos-http-redirect-00
Specifically:
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.
See also: http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
Test script at: https://gist.github.com/330963 tests T4 and T8 (note that the "FAIL/PASS" determinations assume that the resolution would align with draft-bos-http-redirect).
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/295