It's easy or negligible either way for a Subscriber in most cases. The need to ensure correct URL encoding means most of them will be bypassing POST parameter setting, and setting the raw POST body themselves. Most http clients allow raw POST body setting out of a similar necessity.
Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Brett Slatkin <[email protected]> To: [email protected] Sent: Mon, October 19, 2009 5:24:08 PM Subject: [pubsubhubbub] Re: hub.verify - clarification on repeated keywords/parameters? On Mon, Oct 19, 2009 at 12:21 PM, Julien Genestoux <[email protected]> wrote: > > Huh... The http params parser that we use (in ruby) messes up with that... > :/ > > I'll see I'd there is any way around. Yeah? Let's see how hard this is to get right from both the client (subscriber) and server (hub) perspectives. If it's easy for a client and hard for a Hub, that's fine. The subscriber is the important part. > On Oct 19, 2009, at 9:12 AM, Brett Slatkin <[email protected]> wrote: > >> >> On Mon, Oct 19, 2009 at 11:55 AM, Pádraic Brady <[email protected]> >> wrote: >>> >>> Hi all, >>> >>> Just wondering if we could clarify the construction of the hub.verify >>> parameter in the spec. There are two terms used in Section 6.1 "keyword" >>> and >>> "parameter". My own reading has me interpreting the sentence "This >>> parameter >>> may be repeated to indicate multiple supported modes." as meaning >>> something >>> like: >>> >>> hub.verify=sync&hub.verify=async >>> >>> Whereas the final sentence refers to "Where repeated keywords are used, >>> their order indicates the subscriber's order of preference", which seems >>> to >>> suggest: >>> >>> hub.verify=sync,async >>> >>> I went with the first initially since it seemed to be saying the >>> parameter >>> could be repeated, but I gather Superfeedr (haven't checked the reference >>> hub tests yet) rely on the keywords existing within a single parameter >>> (comma delimited). >>> >>> I'm confused myself as to which is correct. Note that the first does get >>> treated differently by http clients. Some will compact the first >>> automatically into the second example (so they end up the same anyway), >>> others will simply drop one of the parameters instead of compacting them. >> >> Initially it was #2. Then we changed it to #1 in the 0.2 spec. >> Python's CGI module will give you back a set of key/list pairs, with >> the values listed in the order they appeared in the string. >> Query-string encoding does enough variable munging that we shouldn't >> have to add yet another level of parsing on top of that, which is why >> we're going with #1. How hard is it to make this work right in PHP for >> clients? >
