>>> 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
Original issue reported on code.google.com by
bslatkin
on 21 Oct 2009 at 9:26