Hey Tim, On Sun, Oct 18, 2009 at 9:22 AM, Tim Bray <[email protected]> wrote: > >> On Sun, Oct 18, 2009 at 6:09 AM, Pádraic Brady <[email protected]> >> wrote: >>> Presumably the secret is not a string of characters but a randomly generated >>> stream of bytes. Bytes != Characters. Character encoding is not relevant. > > Sorry, my initial report was bogus, I hadn't checked > http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.4 > > 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. You have to send them as > %26%66... and so on. -T
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. Tim: Is there a specific action item here or issue I can file? It sounds like you now fully understand the intent of the spec, but maybe this could be more clear somehow? -Brett
