[tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#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:  9
  roadmap-november, tbb-9.5,                     |
  TorBrowserTeam202001R                          |
Parent ID:  #30024                               |         Points:  6
 Reviewer:  pospeselr, mcs, brade                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by pospeselr):

 **Backend**

 So one weird thing that stands about the changes to nsHttpChannel.cpp is
 that the new {{{Onion-Location}}} code seems to supersede all logic
 surrounding the returned HTTP Status. Whether that's okay or not kind of
 depends on the {{{Onion-Location}}} spec.

 How are properly configured web-servers meant to use the {{{Onion-
 Location}}} header? Is it meant to be there in every HTTP response sent to
 the client, or only in certain situations? The spec is unclear about which
 HTTP status codes it is meant to be used with. It does state that
 {{{Onion-Location}}} has the same restrictions and semantics as
 {{{Location}}} which according to [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Headers/Location Mozilla] only has meaning for {{{3XX}}}
 and {{{201}}} responses.

 If we are only supposed to redirect in those contexts then the checks for
 that block checking for and getting the {{{Onion-Location}}} header could
 (probably?) go down into {{{nsHttpChannel::AsyncProcessDirection}}}.

 We don't seem to check if we are *already* on the Onion site the {{{Onion-
 Location}}} header suggests we redirect to.

 **Frontend**

 The frontend logic seems good to me.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:96>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online