hub.challenge should be percent-encoded bytes

[GoogleCodeExporter]

>>> It's like this: Suppose you generate a hub.secret string and it
>>> contains the hex bytes 26 66 66 66 3D 62 61 72.  Well, you can't just
>>> stick those into a application/x-www-form-urlencoded message body "as
>>> bytes" without getting a nasty surprise.
>
>> Escaping the challenge bytes with percent-encoding is the way you form
>> an application/x-www-form-urlencoded POST body or query string. So
>> we'd assume that's how the Hub MUST do it, since it's following the
>> escaping conventions from the HTML 4.01 spec.
>>
>> The subscriber would decode those bytes (as it normally would when
>> parsing a query string) and then echo the decoded bytes back to the
>> Hub as the challenge response. For most of the web frameworks out
>> there this can be implemented in the most natural way possible, with
>> no calls to any escaping function at all (it all happens under the
>> covers). Agreed with Pádraic that this avoids char encodings
>> altogether.
>
> I agree entirely.  I just think that in the phrase "A
> subscriber-provided secret string (as bytes) that will be used ", the
> "(as bytes)" is unnecessary and maybe actively harmful.  It's going to
> make people think "huh? you mean I don't have to %-escape?"  It's a
> string, that's all.  If the string contains funny characters your
> library will probably do the right encoding and decoding. I'm just
> suggesting either lose "(as bytes)" or add a bunch more explanation
> along the lines you give above. I prefer the former.  But maybe I'm
> missing something.

Original issue reported on code.google.com by bslatkin on 21 Oct 2009 at 9:26

[GoogleCodeExporter]

Original comment by bslatkin on 8 Feb 2010 at 11:51

• Added labels: spec0.3

[GoogleCodeExporter]

Addressed in 0.3 draft spec

Original comment by bslatkin on 9 Feb 2010 at 6:05

• Changed state: Fixed