Extension proposal: Canonical feed URLs for easier pinging about pubsubhubbub

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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