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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:  Sponsor4
--------------------------+------------------------------------
Description changed by arma:

Old description:

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

New description:

 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 if 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#comment:2>
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