Reconsider behavior on .z URLs with Accept-Encoding header
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 (moved) 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 (moved), 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.