It's not difficult at all in PHP - it means the parameters should be parsed outside of the PHP mechanism (which is fudgy as hell anyway) but it's just a few simple lines of code. It's necessary in any case to ensure compliance with RFC3986.
Mainly, since it was failing in Superfeedr I wasn't sure if it was a bug on my side or Julien's or something in between. It looks now like a 0.1 to 0.2 migration issue for Superfeedr - so I can keep the original behaviour in my code. Really can't wait for all Hubs to finish migrating to 0.2 ;). Thanks for the clarification. Paddy 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:12:38 PM Subject: [pubsubhubbub] Re: hub.verify - clarification on repeated keywords/parameters? 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?
