Closed GoogleCodeExporter closed 9 years ago
This issue is closely related to the insistence of the spec right now to have
the
subscriber use the <link rel="self"...> URL as the one for actual subscription
(see
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#discover
y).
In practice, subscribers aren't going to do this properly. We need something
better.
I coded up a prototype to get around this limitation. Essentially, the Hub keeps
track of a mapping from topic URL to feed ID, and then feed ID to topic URLs
(plural!). At subscribe time, we derive the feed ID (if the topic hasn't been
seen
before) and save it in association with the topic URL. At publish time, we
figure out
the corresponding feed ID is, then use the reverse index to find all aliases
affected
by the published ping.
For RSS we just use the channel link, because there's no feed ID.
Original comment by bslatkin
on 3 Sep 2009 at 8:50
I believe this has been fixed by r275. I'll be rolling this out to production
and
updating all KnownFeed instances as soon as I finish more system testing.
Original comment by bslatkin
on 21 Sep 2009 at 10:19
Note that the silliness from the spec we want to avoid is:
"Per the Atom spec, the //atom:feed/link[@rel="self"] element MUST indicate the
topic
URL for the original event stream. Subscribers MUST use the self link when
requesting
a subscription from the hub. Subscribers MUST NOT use the original URL from
before
following HTTP redirects to fetch the feed. This is crucial for subscribers to
detect
feed moves.
Hubs MUST use the same URL for both the publishing and subscribing interfaces,
which
is why only a single atom:link element is required to declare a hub. Publishers
SHOULD use HTTPS (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L.,
Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .)
[RFC2616] in their hubs' discovery URLs. However, subscribers that do not
support
HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] MAY try to
fallback to
HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach,
P., and
T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) [RFC2616],
which MAY
work depending on the hub's policy. "
Original comment by bslatkin
on 21 Sep 2009 at 10:30
Original issue reported on code.google.com by
bslatkin
on 22 Jul 2009 at 5:18