Failed to decode requested authority digest

[Nick Mathewson]

> Quoth Nick Mathewson <nickm at torproject.org>, on 2010-01-14 21:49:33 -0500:

Nevermore!

>> > Jan 12 08:57:59.119 [warn] Failed to decode requested authority digest
>> > 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4.
>> > Jan 14 11:40:05.641 [warn] Failed to decode requested authority digest
>> > 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4.
>>
>> This looks like some kind of broken client to me. =A0Look at all those
>> %20s in the string: that looks like http encoding of a space (" ")
>> character, so somebody's program is requesting "14C131 27B6B5 585769
>> 81349F E2A2AF E8A9C4" with the spaces HTTP-encoded. =A0Unless I'm
>> mistaken, the proper format is using + signs, not spaces.
>
> If you mean URI-encoded (or URL-encoded), which HTTP uses, then %20 is
> a valid encoding of a 0x20 (ASCII space) character. =A0+ is a secondary
> convention that's used in query strings only, which can also mean a
> space character. =A0Does the Tor directory request protocol specify
> something else?

For this URL, dir-spec.txt specifies:

     http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z

  Where F1, F2, etc. are authority identity fingerprints the client trusts=
.
  Servers will only return a consensus if more than half of the requested
  authorities have signed the document, otherwise a 404 error will be sent
  back.  The fingerprints can be shortened to a length of any multiple of
  two, using only the leftmost part of the encoded fingerprint.  Tor uses
  3 bytes (6 hex characters) of the fingerprint.

The last sentence should probably start "The Tor client uses..."

The plus signs have been required as long as I can remember, though I
agree that a more standards-friendly use of HTTP would accept any
equivalent URI-encoded string. I'd welcome a patch or two to handle
proper URI-encoding better, or alternatively a patch to dir-spec.txt
to be more explicit about anything at all.

>  The dir-spec.txt document from Tor 0.2.1.20 doesn't
> seem to be clear on how <fp> is interpreted in URIs.

Agreed.  The closest it comes is saying,

]      http://<hostname>/tor/status-vote/next/<fp>.z
]   where <fp> is the fingerprint of the other authority's identity key.