[tor-bugs] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
------------------------------+--------------------------------
     Reporter:  nickm         |      Owner:
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: 0.3.1.x-final
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:  Sponsor4      |
------------------------------+--------------------------------
 In proposal 278, I said:
 {{{
   If a directory server receives a request to a document with the ".z"
   suffix, where the client does not include an "Accept-Encoding" header,
   the server should respond with the zlib compressed version of the
   document for backwards compatibility with client that does not support
   this proposal.
 }}}

 But on #22206 it became apparent that we've got a problem there: there are
 already tools (built e.g. on wget) that ask for the .z URL but which send
 "Accept-Encodings: Identity."

 And onn #22206, Yawning says:
 > an error (or a double compressed payload) should be returned when the .z
 request contains an Accept-Encoding header that specifies anything other
 than identity/deflate.

 We'd like the end result here to be something where new Tor clients can
 interoperate with older directory caches without breaking anything, and
 getting the new compression type of they support it.  And we certainly
 don't want anybody doing two layers of compression: that's a waste of
 cycles.  But we should see if there's a way where we can be more standards
 compliant without breaking anything we care about.

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