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

Ticket #43 (closed design: fixed)

Opened 7 years ago

Last modified 3 years ago

Fragment combination / precedence during redirects

Reported by: mnot@pobox.com Owned by: ylafon@w3.org
Priority: urgent Milestone: 13
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103.html

Description

At present, the behavior in the case where there was a fragment with the original URI, e.g.: http://host1.example.com/resource1#fragment1 where /resource1 redirects to http://host2.example.com/resource2#fragment2 is 'fragment1' discarded? Do you find fragment2 and then find fragment1 within it? We don't have fragment combination rules.

Attachments

i43.diff (8.5 KB) - added by julian.reschke@gmx.de 4 years ago.
Proposed patch for parts 1 & 2.
redir_frag_test.py (6.8 KB) - added by mnot@pobox.com 4 years ago.
test script
i43.2.diff (979 bytes) - added by julian.reschke@gmx.de 4 years ago.
proposed patch, addressing the TAG input.
i43resolution.diff (2.3 KB) - added by julian.reschke@gmx.de 3 years ago.
an attempt to describe the resolution algorithm

Change History

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

  • Component set to semantics
  • Milestone set to unassigned

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

  • version set to 00-draft

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

  • Origin changed from issue 6 to http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103.html

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

Could add note to Location header that combining fragments may have unpredictable results.

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

  • Owner set to julian.reschke@gmx.de
  • Priority set to normal

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

I just tested this with various browsers.

  • Firefox and Safari use the fragment in the location header.
  • Opera uses the fragment from the source URI, when present, otherwise

the fragment from the redirect location

  • IE (8) ignores the fragment in the location URI, thus will use the

fragment from the source URI, when present

Proposal:

"Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence."

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

It appears that IE8 *does* use the fragment idenfitier from Location (the behavior I saw might be limited to localhost).

Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.

I therefore change my proposal to document *that* as expected behavior.

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

  • Milestone changed from unassigned to 08

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

  • Severity set to Active WG Document
  • Milestone changed from 08 to 09

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

  • Priority changed from normal to urgent
  • Milestone changed from 09 to 10

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

  • Status changed from new to assigned

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

Proposed patch for parts 1 & 2.

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

From [785]:

Allow URI-reference instead of URI in Location; state that there are currently no defined precedence rules for fragment identifiers (relates to #43 and #185)

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

Note that the test cases mentioned above are broken; see http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0265.html. Need to re-investigate this.

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

comment:16 Changed 4 years ago by mnot@pobox.com

The remaining question is: do we want to define it, or do we believe this depends on the media type?

Changed 4 years ago by mnot@pobox.com

test script

comment:17 Changed 4 years ago by mnot@pobox.com

I quickly re-tested the latest browsers:

IE9p3: all passed Safari 5 (OSX): fails T4, T8 FF 3.6.6: all passed Chrome 5.0.375.99: all passed Opera 10.60: fails T3, T7

comment:18 Changed 4 years ago by mnot@pobox.com

Let's try that with a bit of formatting:

  • IE9p3: all passed
  • Safari 5 (OSX): fails T4, T8
  • FF 3.6.6: all passed
  • Chrome 5.0.375.99: all passed
  • Opera 10.60: fails T3, T7

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

  • Owner changed from julian.reschke@gmx.de to ylafon@w3.org
  • Status changed from assigned to new
  • Milestone changed from 10 to 11

comment:20 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from 11 to unassigned

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

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

proposed patch, addressing the TAG input.

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

From [1097]:

Add additional warning on fragids on redirects potentially causing inconvenience (as requested by the TAG) (see #43)

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

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

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

  • Milestone changed from unassigned to 13

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

  • Status changed from reopened to closed
  • Resolution set to fixed

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

an attempt to describe the resolution algorithm

Note: See TracTickets for help on using tickets.