#295: Applying original fragment to "plain" redirected URI (also #43)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

#295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2
New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>

As Eric Lawrence pointed out on his blog:
  http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.

As mentioned in #43, 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.
"""

By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.

I see two possible ways forward:
  1) As with #43, explicitly state that there isn't interop here.
  2) Define interop along the lines of draft-bos-http-redirect.

I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.

However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.


Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.

This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?

Regards,


* Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.

** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Adam Barth-5
My understanding is that preserving the fragment across the redirect
is a net positive for compatibility on the web.  In fact, Eric's blog
post mentions that he learned about the behavior by investigating
compat problems that IE faces because it lacks this behavior.  I
certainly agree that it would be nice to make the specs less cloudy in
this regard.  :)

Adam


On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <[hidden email]> wrote:

> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>
> As Eric Lawrence pointed out on his blog:
>  http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
>
> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>
> As mentioned in #43, 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.
> """
>
> By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>
> I see two possible ways forward:
>  1) As with #43, explicitly state that there isn't interop here.
>  2) Define interop along the lines of draft-bos-http-redirect.
>
> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>
> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>
>
> Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.
>
> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>
> Regards,
>
>
> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>
> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: #295: Applying original fragment to "plain" redirected URI (also #43)

Eric Lawrence-4
I've filed an issue in our database for consideration in IE10.

Having HTTPBIS clearly call for this behavior will definitely help support the case for making a change.

thanks,
Eric Lawrence

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Adam Barth
Sent: Thursday, May 26, 2011 8:46 PM
To: Mark Nottingham
Cc: httpbis Group
Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)

My understanding is that preserving the fragment across the redirect is a net positive for compatibility on the web.  In fact, Eric's blog post mentions that he learned about the behavior by investigating compat problems that IE faces because it lacks this behavior.  I certainly agree that it would be nice to make the specs less cloudy in this regard.  :)

Adam


On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <[hidden email]> wrote:

> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>
> As Eric Lawrence pointed out on his blog:
>  
> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-a
> nd-redirects-anchor-hash-missing.aspx
>
> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>
> As mentioned in #43, 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.
> """
>
> By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>
> I see two possible ways forward:
>  1) As with #43, explicitly state that there isn't interop here.
>  2) Define interop along the lines of draft-bos-http-redirect.
>
> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>
> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>
>
> Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.
>
> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>
> Regards,
>
>
> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>
> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2
Thanks, Eric -- that's very helpful.

Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect?

Cheers,


On 28/05/2011, at 10:58 AM, Eric Lawrence wrote:

> I've filed an issue in our database for consideration in IE10.
>
> Having HTTPBIS clearly call for this behavior will definitely help support the case for making a change.
>
> thanks,
> Eric Lawrence
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Adam Barth
> Sent: Thursday, May 26, 2011 8:46 PM
> To: Mark Nottingham
> Cc: httpbis Group
> Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
>
> My understanding is that preserving the fragment across the redirect is a net positive for compatibility on the web.  In fact, Eric's blog post mentions that he learned about the behavior by investigating compat problems that IE faces because it lacks this behavior.  I certainly agree that it would be nice to make the specs less cloudy in this regard.  :)
>
> Adam
>
>
> On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <[hidden email]> wrote:
>> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>>
>> As Eric Lawrence pointed out on his blog:
>>  
>> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-a
>> nd-redirects-anchor-hash-missing.aspx
>>
>> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>>
>> As mentioned in #43, 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.
>> """
>>
>> By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>>
>> I see two possible ways forward:
>>  1) As with #43, explicitly state that there isn't interop here.
>>  2) Define interop along the lines of draft-bos-http-redirect.
>>
>> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>>
>> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>>
>>
>> Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.
>>
>> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>>
>> Regards,
>>
>>
>> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>>
>> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Adam Barth-5
draft-bos-http-redirect looks fine.  One quibble:

[[
Security considerations

   No new security considerations are added to those already present in
   HTTP 1.1.
]]

This behavior does contain a (slight) security risk in that a server
might inadvertently leak a fragment containing a secret to another
server in this way.

Adam


On Fri, May 27, 2011 at 6:07 PM, Mark Nottingham <[hidden email]> wrote:

> Thanks, Eric -- that's very helpful.
>
> Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect?
>
> Cheers,
>
>
> On 28/05/2011, at 10:58 AM, Eric Lawrence wrote:
>
>> I've filed an issue in our database for consideration in IE10.
>>
>> Having HTTPBIS clearly call for this behavior will definitely help support the case for making a change.
>>
>> thanks,
>> Eric Lawrence
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Adam Barth
>> Sent: Thursday, May 26, 2011 8:46 PM
>> To: Mark Nottingham
>> Cc: httpbis Group
>> Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
>>
>> My understanding is that preserving the fragment across the redirect is a net positive for compatibility on the web.  In fact, Eric's blog post mentions that he learned about the behavior by investigating compat problems that IE faces because it lacks this behavior.  I certainly agree that it would be nice to make the specs less cloudy in this regard.  :)
>>
>> Adam
>>
>>
>> On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <[hidden email]> wrote:
>>> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>>>
>>> As Eric Lawrence pointed out on his blog:
>>>
>>> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-a
>>> nd-redirects-anchor-hash-missing.aspx
>>>
>>> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>>>
>>> As mentioned in #43, 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.
>>> """
>>>
>>> By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>>>
>>> I see two possible ways forward:
>>>  1) As with #43, explicitly state that there isn't interop here.
>>>  2) Define interop along the lines of draft-bos-http-redirect.
>>>
>>> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>>>
>>> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>>>
>>>
>>> Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.
>>>
>>> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>>>
>>> Regards,
>>>
>>>
>>> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>>>
>>> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2
In reply to this post by Mark Nottingham-2
I haven't heard any negative responses, so marking for incorporation into -15.


On 28/05/2011, at 11:07 AM, Mark Nottingham wrote:

> Thanks, Eric -- that's very helpful.
>
> Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect?
>
> Cheers,
>
>
> On 28/05/2011, at 10:58 AM, Eric Lawrence wrote:
>
>> I've filed an issue in our database for consideration in IE10.
>>
>> Having HTTPBIS clearly call for this behavior will definitely help support the case for making a change.
>>
>> thanks,
>> Eric Lawrence
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Adam Barth
>> Sent: Thursday, May 26, 2011 8:46 PM
>> To: Mark Nottingham
>> Cc: httpbis Group
>> Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
>>
>> My understanding is that preserving the fragment across the redirect is a net positive for compatibility on the web.  In fact, Eric's blog post mentions that he learned about the behavior by investigating compat problems that IE faces because it lacks this behavior.  I certainly agree that it would be nice to make the specs less cloudy in this regard.  :)
>>
>> Adam
>>
>>
>> On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <[hidden email]> wrote:
>>> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>>>
>>> As Eric Lawrence pointed out on his blog:
>>>
>>> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-a
>>> nd-redirects-anchor-hash-missing.aspx
>>>
>>> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>>>
>>> As mentioned in #43, 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.
>>> """
>>>
>>> By my testing <https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>>>
>>> I see two possible ways forward:
>>> 1) As with #43, explicitly state that there isn't interop here.
>>> 2) Define interop along the lines of draft-bos-http-redirect.
>>>
>>> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>>>
>>> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>>>
>>>
>>> Regarding #43 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.
>>>
>>> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>>>
>>> Regards,
>>>
>>>
>>> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>>>
>>> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
In reply to this post by Mark Nottingham-2
On 2011-05-28 03:07, Mark Nottingham wrote:
> Thanks, Eric -- that's very helpful.
>
> Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect?
> ...

My concern is similar to what was brought up in the context of issue 43
-- it's not entirely clear whether HTTPbis has any business in defining
this (that is; is this an aspect of media types or of redirects?).

I don't think we ever came to a conclusion about this in the context of
#43, as, in the end, we didn't define the behavior.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2

On 02/07/2011, at 3:36 AM, Julian Reschke wrote:

> On 2011-05-28 03:07, Mark Nottingham wrote:
>> Thanks, Eric -- that's very helpful.
>>
>> Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect?
>> ...
>
> My concern is similar to what was brought up in the context of issue 43 -- it's not entirely clear whether HTTPbis has any business in defining this (that is; is this an aspect of media types or of redirects?).
>
> I don't think we ever came to a conclusion about this in the context of #43, as, in the end, we didn't define the behavior.

My recollection was that we didn't have interop in browsers, and we didn't have an indication of a strong desire from them one way or the other. I'd say we have both now.

Perhaps we should ping the TAG to get their thoughts? Absent strong objection, it seems like we can have an easy interop win here.


--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
In reply to this post by Mark Nottingham-2
On 2011-05-27 05:32, Mark Nottingham wrote:

> New issue:<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>
> As Eric Lawrence pointed out on his blog:
>    http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
>
> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
>
> As mentioned in #43, 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.
> """
>
> By my testing<https://gist.github.com/330963>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
>
> I see two possible ways forward:
>    1) As with #43, explicitly state that there isn't interop here.
>    2) Define interop along the lines of draft-bos-http-redirect.
>
> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
>
> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
>
>
> Regarding #43<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.

Indeed; see my tests at
<http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that
Safari appears to have funny issues filling the iframes; but navigating
to the linked resource gets you proper results).

And, in a later mail:

>> My concern is similar to what was brought up in the context of issue 43 -- it's not entirely clear whether HTTPbis has any business in defining this (that is; is this an aspect of media types or of redirects?).
>>
>> I don't think we ever came to a conclusion about this in the context of #43, as, in the end, we didn't define the behavior.
> My recollection was that we didn't have interop in browsers, and we didn't have an indication of a strong desire from them one way or the other. I'd say we have both now.
>
> Perhaps we should ping the TAG to get their thoughts? Absent strong objection, it seems like we can have an easy interop win here.

We could try (cc'ing Larry so he sees this), but we'd need a reply very
soon :-)

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
On 2011-12-30 18:51, Julian Reschke wrote:
> ...
> Indeed; see my tests at
> <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that
> Safari appears to have funny issues filling the iframes; but navigating
> to the linked resource gets you proper results).
> ...

I just realized that the rule we would need to describe *almost* is the
one define in the URI spec
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as
"relative resolution":

>    -- The URI reference is parsed into the five URI components
>    --
>    (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
>
>    -- A non-strict parser may ignore a scheme in the reference
>    -- if it is identical to the base URI's scheme.
>    --
>    if ((not strict) and (R.scheme == Base.scheme)) then
>       undefine(R.scheme);
>    endif;
>
>    if defined(R.scheme) then
>       T.scheme    = R.scheme;
>       T.authority = R.authority;
>       T.path      = remove_dot_segments(R.path);
>       T.query     = R.query;
>    else
>       if defined(R.authority) then
>          T.authority = R.authority;
>          T.path      = remove_dot_segments(R.path);
>          T.query     = R.query;
>       else
>          if (R.path == "") then
>             T.path = Base.path;
>             if defined(R.query) then
>                T.query = R.query;
>             else
>                T.query = Base.query;
>             endif;
>          else
>             if (R.path starts-with "/") then
>                T.path = remove_dot_segments(R.path);
>             else
>                T.path = merge(Base.path, R.path);
>                T.path = remove_dot_segments(T.path);
>             endif;
>             T.query = R.query;
>          endif;
>          T.authority = Base.authority;
>       endif;
>       T.scheme = Base.scheme;
>    endif;
>
>    T.fragment = R.fragment;

"Almost", because it doesn't use Base.fragment when R.frament is undefined.

a) Should we try describe the algorithm based on RFC 3986 ("do relative
resolution as defined by ..., then, if the result doesn't have a
fragment, add the one from the Base URI")?

b) Is this potentially an erratum for RFC 3986?

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

RE: #295: Applying original fragment to "plain" redirected URI (also #43)

masinter
...

"Almost", because it doesn't use Base.fragment when R.frament is undefined.

a) Should we try describe the algorithm based on RFC 3986 ("do relative resolution as defined by ..., then, if the result doesn't have a fragment, add the one from the Base URI")?
b) Is this potentially an erratum for RFC 3986?

a) sounds good.
b) I'd call it an "update" rather than an erratum.

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Amos Jeffries-2
In reply to this post by Julian Reschke
On 4/01/2012 3:43 a.m., Julian Reschke wrote:
>
> "Almost", because it doesn't use Base.fragment when R.frament is
> undefined.
>
> a) Should we try describe the algorithm based on RFC 3986 ("do
> relative resolution as defined by ..., then, if the result doesn't
> have a fragment, add the one from the Base URI")?

+1 on this.

>
> b) Is this potentially an erratum for RFC 3986?
>

um.

AYJ

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Willy Tarreau-3
On Wed, Jan 04, 2012 at 06:12:06PM +1300, Amos Jeffries wrote:

> On 4/01/2012 3:43 a.m., Julian Reschke wrote:
> >
> >"Almost", because it doesn't use Base.fragment when R.frament is
> >undefined.
> >
> >a) Should we try describe the algorithm based on RFC 3986 ("do
> >relative resolution as defined by ..., then, if the result doesn't
> >have a fragment, add the one from the Base URI")?
>
> +1 on this.

+1 too.

Willy


Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Martin J. Dürst
In reply to this post by Julian Reschke
Hello Julian, others,

On 2012/01/03 23:43, Julian Reschke wrote:

> On 2011-12-30 18:51, Julian Reschke wrote:
>> ...
>> Indeed; see my tests at
>> <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that
>> Safari appears to have funny issues filling the iframes; but navigating
>> to the linked resource gets you proper results).
>> ...
>
> I just realized that the rule we would need to describe *almost* is the
> one define in the URI spec
> (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as
> "relative resolution":

> "Almost", because it doesn't use Base.fragment when R.frament is undefined.
>
> a) Should we try describe the algorithm based on RFC 3986 ("do relative
> resolution as defined by ..., then, if the result doesn't have a
> fragment, add the one from the Base URI")?

I'm not at all sure that this description is correct. It would mean that
I can have something like:
Request URI:   http://1.example.org/path1/file1.ext
Redirect URI:  http://2.example.org#frag2

and the result would be:
http://2.example.org/path1/file1.ext#frag2

As you can see in the result, there is a mixture of components from the
request URI (1) and the redirect URI (2). The way that relative
resolution works otherwise is that in the result, all components from
(2) precede components from (1).

Below is the change to the algorithm that I'd think is correct. In
logical terms, it's straightforward: Use the fragment from the "base"
only if nothing before the fragment is coming from the "resource".
However, in terms of actual code, there are quite a few places to
change. This is because the if/else hierarchy gets deeper and deeper for
the later parts of the URI. In the algorithm, scheme is set in two
locations, authority in three, and so on. The structure of the code gets
even more regular if you change
    if (R.path == "") then
to
    if (R.path != "") then
(which is equivalent to "if defined(R.path) then") and exchange the
respective code blocks. The only irregularity in the structure then is the
    if (R.path starts-with "/") then
condition; this could be regularized by separating path (without the
actual final name of the resource) and pure resource (file) name.

 >>>>
    -- The URI reference is parsed into the five URI components
    --
    (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);

    -- A non-strict parser may ignore a scheme in the reference
    -- if it is identical to the base URI's scheme.
    --
    if ((not strict) and (R.scheme == Base.scheme)) then
       undefine(R.scheme);
    endif;

    if defined(R.scheme) then
       T.scheme    = R.scheme;
       T.authority = R.authority;
       T.path      = remove_dot_segments(R.path);
       T.query     = R.query;
       T.fragment  = R.fragment;               -- this line added
    else
       if defined(R.authority) then
          T.authority = R.authority;
          T.path      = remove_dot_segments(R.path);
          T.query     = R.query;
          T.fragment  = R.fragment;            -- this line added
       else
          if (R.path == "") then
             T.path = Base.path;
             if defined(R.query) then
                T.query = R.query;
                T.fragment = R.fragment;       -- this line added
             else
                T.query = Base.query;
                if defined(R.fragment) then    -- this line added
                   T.fragment  = R.fragment;   -- this line added
                else                           -- this line added
                   T.fragment = Base.fragment; -- this line added
                endif;                         -- this line added
             endif;
          else
             if (R.path starts-with "/") then
                T.path = remove_dot_segments(R.path);
             else
                T.path = merge(Base.path, R.path);
                T.path = remove_dot_segments(T.path);
             endif;
             T.query = R.query;
             T.fragment = R.fragment;          -- this line added
          endif;
          T.authority = Base.authority;
       endif;
       T.scheme = Base.scheme;
    endif;

    -- T.fragment = R.fragment;                -- this line commented out
 >>>>

It's also possible to rewrite this as:

 >>>>
    -- The URI reference is parsed into the five URI components
    --
    (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
    T.fragment = undefined;                    -- this line added

    -- A non-strict parser may ignore a scheme in the reference
    -- if it is identical to the base URI's scheme.
    --
    if ((not strict) and (R.scheme == Base.scheme)) then
       undefine(R.scheme);
    endif;

    if defined(R.scheme) then
       T.scheme    = R.scheme;
       T.authority = R.authority;
       T.path      = remove_dot_segments(R.path);
       T.query     = R.query;
    else
       if defined(R.authority) then
          T.authority = R.authority;
          T.path      = remove_dot_segments(R.path);
          T.query     = R.query;
       else
          if (R.path == "") then
             T.path = Base.path;
             if defined(R.query) then
                T.query = R.query;
             else
                T.query = Base.query;
                if not defined(R.fragment) then  -- this line added
                   T.fragment = Base.fragment;   -- this line added
                endif;                           -- this line added
             endif;
          else
             if (R.path starts-with "/") then
                T.path = remove_dot_segments(R.path);
             else
                T.path = merge(Base.path, R.path);
                T.path = remove_dot_segments(T.path);
             endif;
             T.query = R.query;
          endif;
          T.authority = Base.authority;
       endif;
       T.scheme = Base.scheme;
    endif;

    if not defined(T.fragment) then            -- this line added
       T.fragment = R.fragment;
    endif;                                     -- this line added
 >>>>

This localizes the changes better and can probably serve as the base (no
pun intended) for spec text.


> b) Is this potentially an erratum for RFC 3986?

I would say NO. My understanding is that something like
    <a href="">a link</a>
always refers to the resource itself, not a subresource. If the erratum
went through, there would be no short way to refer to a resource itself.

Regards,    Martin.

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
On 2012-01-04 11:27, "Martin J. Dürst" wrote:

> Hello Julian, others,
>
> On 2012/01/03 23:43, Julian Reschke wrote:
>> On 2011-12-30 18:51, Julian Reschke wrote:
>>> ...
>>> Indeed; see my tests at
>>> <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that
>>> Safari appears to have funny issues filling the iframes; but navigating
>>> to the linked resource gets you proper results).
>>> ...
>>
>> I just realized that the rule we would need to describe *almost* is the
>> one define in the URI spec
>> (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as
>> "relative resolution":
>
>> "Almost", because it doesn't use Base.fragment when R.frament is
>> undefined.
>>
>> a) Should we try describe the algorithm based on RFC 3986 ("do relative
>> resolution as defined by ..., then, if the result doesn't have a
>> fragment, add the one from the Base URI")?
>
> I'm not at all sure that this description is correct. It would mean that
> I can have something like:
> Request URI: http://1.example.org/path1/file1.ext
> Redirect URI: http://2.example.org#frag2
>
> and the result would be:
> http://2.example.org/path1/file1.ext#frag2
> ...

I think that's incorrect.

This should be resolved as per:

    if defined(R.scheme) then
       T.scheme    = R.scheme;
       T.authority = R.authority;
       T.path      = remove_dot_segments(R.path);
       T.query     = R.query;
    else
       (left out)
    endif;

    T.fragment = R.fragment;

thus to

    http://2.example.org#frag2

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
In reply to this post by masinter
On 2012-01-04 05:57, Larry Masinter wrote:
> ...
>
> "Almost", because it doesn't use Base.fragment when R.frament is undefined.
>
> a) Should we try describe the algorithm based on RFC 3986 ("do relative resolution as defined by ..., then, if the result doesn't have a fragment, add the one from the Base URI")?
> b) Is this potentially an erratum for RFC 3986?
>
> a) sounds good.
> b) I'd call it an "update" rather than an erratum.

OK, here's an attempt to describe this:

Appendix A.  Base Fragment Aware Relative Resolution

    Section 5.2 of [RFC3986] defines the Relative Resolution of a URI
    reference against a Base URI.  That algorithm however does not take a
    fragment identifier on the Base URI into account.

    However in some cases, as when following a redirect from a URI "Base"
    based on a Location header field containing the URI reference "R", it
    can be necessary to preserve a fragment identifier present on "Base".
    The algorithm described below does this:

    Given a URI reference "R" and a base URI "Base", to transform R into
    its target URI "T":

    (1) Pre-parse the Base URI as defined in Section 5.2.1 of [RFC3986].

    (2) Transform references as defined in Section 5.2.2 of [RFC3986].
    If the T.fragment is undefined and Base.fragment is defined, then set
    T.fragment to Base.fragment:

      if defined(Base.fragment) and not(defined(T.fragment)) then
        T.fragment = Base.fragment;
      endif;

    (3) Merge paths as defined in Section 5.2.3 of [RFC3986].

    (4) Remove dot segments as defined in Section 5.2.4 of [RFC3986].

    (5) Finally, recompose the components as defined in Section 5.3 of
    [RFC3986].

A.1.  Examples

    Starting with a Base URI of "http://host/path1#f1":

    +-----------+------------------------+------------------------------+
    | R         | T (after RFC 3986      | T (after Base Fragment Aware |
    |           | Relative Resolution)   | Relative Resolution)         |
    +-----------+------------------------+------------------------------+
    | /path2    | http://host/path2      | http://host/path2#f1         |
    | /path2#f2 | http://host/path2#f2   | http://host/path2#f2         |
    +-----------+------------------------+------------------------------+


(this could be an HTTPbis appendix or a standalone document if it's
needed elsewhere)

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Roy T. Fielding
Sorry, I'm not following this logic at all.  Reusing the original fragment
after a redirect is, at best, fallback behavior that would occur *inside*
the user agent renderer after URI parsing is done, after the redirect is
done, and without any reference to the Location URI.  In short, this whole
approach is wrong (and confusing).

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Julian Reschke
On 2012-01-05 22:48, Roy T. Fielding wrote:
> Sorry, I'm not following this logic at all.  Reusing the original fragment
> after a redirect is, at best, fallback behavior that would occur *inside*
> the user agent renderer after URI parsing is done, after the redirect is
> done, and without any reference to the Location URI.  In short, this whole
> approach is wrong (and confusing).
> ...

OK, I think I see what you mean.

Going back to what we currently have in
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.3>:

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

and in
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>:

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

(which was the result of negotiating the text with the W3C TAG, see
issue #43).

The note we added back then already mentions fragment identifiers on the
"original URI".

We need to decide whether to re-open #43 (fragment recombination), and
what to do #295.

The three interesting cases are:

(1) <http://greenbytes.de/tech/tc/httpredirects/#tfnry>:
http://example.com/test1 redirect-to http://example.com/test2#A yields ?

(2) <http://greenbytes.de/tech/tc/httpredirects/#tfyry>:
http://example.com/test1#B redirect-to http://example.com/test2#A yields ?

(3) <http://greenbytes.de/tech/tc/httpredirects/#tfyrn>:
http://example.com/test1#B redirect-to http://example.com/test2 yields ?

Browsers agree on the first two cases (the fragment from the redirect is
used, so http://example.com/test2#A), but do not completely agree on the
last case (Safari and IE loose the fragment identifier, the others keep
it, ending up with http://example.com/test2#B).

I think we have heard from IE that they want to change to the
Firefox/Chrome/Opera behavior. We don't know about Safari.

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


(and also we would kill
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2

On 08/01/2012, at 2:28 AM, Julian Reschke wrote:

> 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."
>
>
> (and also we would kill <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).

Works for me; +1. Some examples wouldn't go astray.


--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

Mark Nottingham-2
Assigned for -19.

On 01/02/2012, at 4:13 PM, Mark Nottingham wrote:

>
> On 08/01/2012, at 2:28 AM, Julian Reschke wrote:
>
>> 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."
>>
>>
>> (and also we would kill <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).
>
> Works for me; +1. Some examples wouldn't go astray.




--
Mark Nottingham   http://www.mnot.net/




12