On Mon, Oct 19, 2009 at 6:11 PM, Tim Bray <[email protected]> wrote: > > 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.
Cool. I've opened this issue to incorporate the percent encoding clarification in the spec: http://code.google.com/p/pubsubhubbub/issues/detail?id=96
