The onion-location mechanism does not redirect to full URL

I was looking at https://www.torproject.org/download/#android when I got asked about using the onion service instead, which is nice. I opted in but then after the redirect I landed at http://expyuzz4wqqyqhjn.onion/download/index.html

The missing anchor is annoying as I need to scroll down again manually while I have been at the correct place before.

The expectation here is that I am landing at http://expyuzz4wqqyqhjn.onion/download/index.html#android instead.

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-9.5-issues in Legacy / Trac type::defect in Legacy / Trac labels

One way to avoid having to scroll again would be to keep the scroll position when there is the redirect. That might solve the issue when there is no hash in the url, so this solution might be implemented independently.

However, the hash part of the URL (fragment identifier?) is not only used for anchors, but also for other stuff like navigation in single-page applications, etc., so it would be good to preserve it. One idea would be to allow a "relative mode" for Onion-Location, where the value is interpreted as the scheme + host, and the redirect is performed by appending the current path + query params + hash to it. This would also allow to have shorter and simpler Onion-Location headers for websites, and in most cases, to serve the same static Onion-Location header for the whole website.

If we think this is a good idea, then the question would be how to do it in a backwards-compatible way. We could use a trick like: if it starts with http: or https:, treat like an absolute Onion-Location, otherwise, treat like a relative one (and assume it's http:). I guess for a .onion, not redirecting to https directly is not a big issue. Another possible solution would be to use sysrqb's idea of making Onion-Location a structured header. We could then express a "relative" Onion-Location header like Onion-Location: "http://hostname.onion"; relative, for example (a string item and a boolean parameter relative).

Replying to acat:

One way to avoid having to scroll again would be to keep the scroll position when there is the redirect. That might solve the issue when there is no hash in the url, so this solution might be implemented independently.

However, the hash part of the URL (fragment identifier?) is not only used for anchors, but also for other stuff like navigation in single-page applications, etc., so it would be good to preserve it. One idea would be to allow a "relative mode" for Onion-Location, where the value is interpreted as the scheme + host, and the redirect is performed by appending the current path + query params + hash to it. This would also allow to have shorter and simpler Onion-Location headers for websites, and in most cases, to serve the same static Onion-Location header for the whole website.

I understand why this is a useful feature, but I worry about successfully achieving this goal. I think the underlying question is "should reloading a page based on onion-location provide same-origin behavior?". If it should not provide that behavior, then we should simply reload the page using the provided URL without modification. If the behavior should be "same-origin"-like, then I like the idea of providing a "relative" mode. However, if that is the case, then we need to discuss how cookies and storage are shared. I expect some pages contain content depending on a cookie or localstorage, and reloading the page with a different domain may cause weird problems if the anchor isn't valid on the new page or in the SPA. Alt-svc entirely avoids this problem.

For what it's worth, it would be more consistent with HTTP's Location header to preserve fragment identifiers. From https://tools.ietf.org/html/rfc7231#section-7.1.2: If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). The RFC also include some examples. I don't think reusing the fragment component would be harmful in too many cases and we could leave it to the website maintainer to watch out for such problems.

Replying to mcs:

For what it's worth, it would be more consistent with HTTP's Location header to preserve fragment identifiers. From https://tools.ietf.org/html/rfc7231#section-7.1.2: If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). The RFC also include some examples. I don't think reusing the fragment component would be harmful in too many cases and we could leave it to the website maintainer to watch out for such problems.

Thanks, I did not know that. It seems we lost this by basing our implementation in Refresh instead of Location redirects (to avoid issues with the redirect Response codes). Yes, maybe we could just modify our patch to always inherit the fragment (if the Onion-Location doesn't have a fragment already).

Replying to sysrqb:

I understand why this is a useful feature, but I worry about successfully achieving this goal. I think the underlying question is "should reloading a page based on onion-location provide same-origin behavior?". If it should not provide that behavior, then we should simply reload the page using the provided URL without modification. If the behavior should be "same-origin"-like, then I like the idea of providing a "relative" mode. However, if that is the case, then we need to discuss how cookies and storage are shared. I expect some pages contain content depending on a cookie or localstorage, and reloading the page with a different domain may cause weird problems if the anchor isn't valid on the new page or in the SPA. Alt-svc entirely avoids this problem. Treating as the same-origin is an interesting idea, and I think we should consider it (probably has some risks, since this behaviour is not there for Location or any redirects in general). But given that inheriting the fragment already happens with Location, it may be just fine to also implement it for Onion-Location.

moved from legacy/trac#34366 (moved)

added Bug label and removed 1 deleted label

removed 1 deleted label

I just experienced it too. The onion-location mechanism does not redirect to origin URL #parts.

arma: caveman: you might enjoy https://2019.www.torproject.org/docs/faq#ChoosePathLength

The onion redirection broke the anchor link removed by onion-location preference.

hard to fix because the anchor is a local thing, the server doesn't know about it

mentioned in merge request !263 (closed)

marked this issue as related to tor-browser-build#40458 (closed)

marked this issue as related to tor-browser-build#40466 (closed)

added Backport label

mentioned in commit 627f63be

mentioned in issue #40901 (closed)

closed

removed Backport label

mentioned in commit 43429bce