Huh... The http params parser that we use (in ruby) messes up with
that...
:/
I'll see I'd there is any way around.
--
Julien Genestoux
[email protected]
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
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]
m> 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?
