* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #295 (closed design: fixed)

Opened 3 years ago

Last modified 2 years ago

Applying original fragment to "plain" redirected URI

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 19
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin:

Description

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:

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).

Attachments

295.diff (4.7 KB) - added by julian.reschke@gmx.de 2 years ago.
Proposed patch

Change History

comment:1 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 15

comment:2 Changed 3 years ago by julian.reschke@gmx.de

  • Owner changed from draft-ietf-httpbis-p2-semantics@tools.ietf.org to julian.reschke@gmx.de

comment:3 Changed 3 years ago by julian.reschke@gmx.de

  • Owner julian.reschke@gmx.de deleted

comment:4 Changed 3 years ago by julian.reschke@gmx.de

  • Milestone changed from 15 to unassigned

comment:5 Changed 3 years ago by julian.reschke@gmx.de

comment:6 Changed 3 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com

comment:7 Changed 3 years ago by julian.reschke@gmx.de

comment:8 Changed 2 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 19

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>).

Changed 2 years ago by julian.reschke@gmx.de

Proposed patch

comment:9 Changed 2 years ago by julian.reschke@gmx.de

From [1536]:

Location header field: define header field recombination in presence of fragment identifiers, mention security impact, rephrase main definition (see #295)

comment:10 Changed 2 years ago by julian.reschke@gmx.de

  • Status changed from new to closed
  • Resolution set to incorporated

comment:11 Changed 2 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 2 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.