On Mon, Oct 19, 2009 at 6:36 AM, Brett Slatkin <[email protected]> wrote:
>> 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. -Tim
