[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing
#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-------------------------------------------------+-------------------------
Reporter: linda | Owner: acat
Type: project | Status:
| needs_review
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: ux-team, tor-hs, network-team- | Actual Points: 11.6
roadmap-november, tbb-9.5, network-team- |
roadmap-2020Q1, TorBrowserTeam202003R |
Parent ID: #30024 | Points: 6
Reviewer: pospeselr, mcs, brade | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by sysrqb):
acat and I briefly discussed the header format earlier. One piece of
feedback reminded me that we should use X-Onion-Location, because we are
not implementing a standardized HTTP header. However, acat pointed me to
https://tools.ietf.org/html/rfc6648 where `X-*` headers are considered
deprecated. So, we should think a little harder about the format of the
value for this field. The `Location` HTTP header is
[https://tools.ietf.org/html/rfc7231#page-68 defined] as:
{{{
The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of
relationship is defined by the combination of request method and
status code semantics.
Location = URI-reference
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).
For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for
automatically redirecting the request.
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).
For example, a GET request generated for the URI reference
"http://www.example.org/~tim"; might result in a 303 (See Other)
response containing the header field:
Location: /People.html#tim
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim";
Likewise, a GET request generated for the URI reference
"http://www.example.org/index.html#larry"; might result in a 301
(Moved Permanently) response containing the header field:
Location: http://www.example.net/index.html
which suggests that the user agent redirect to
"http://www.example.net/index.html#larry";, preserving the original
fragment identifier.
}}}
In the future, we may find it advantageous if we specify `Onion-Location`
as a [https://httpwg.org/http-extensions/draft-ietf-httpbis-header-
structure.html structured header] with a backwards compatible format
matching that of the Location header.
To be clear, we can use the current implementation and get this into
Nightly builds, but we should think about this idea before the feature
moves to Stable.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:134>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs