Allowing redirects for hubs

[julien51]

Hubs should be able to redirect subscribers and publishers to another hub:
It's likely that hubs will die (some of died already) and if things are really decentralized in the way that the hub does not know about the publishers pointing to it (it's likely and happens a lot), then, we need a way for the hub to tell subscribers it moved.

[pfefferle]

Very good point!

[romkatv]

After thinking about this problem I'm not sure that redirects would work well. First, we would have to use redirects for POST with HTTP 307 (that's the only status code that can redirect a POST request), which isn't a very common thing to do. Here's what http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html has to say:

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

This means the hub users (subscribers and publishers) MUST NOT follow 307 redirect automatically.

Another reason I don't feel comfortable with redirects in the protocol is increased complexity. The protocol is intentionally very easy for subscribers and publishers to implement. If we allow hubs to return redirects, publishers and subscribers will have to learn how to handle them.

[julien51]

I agree with both of your theoretical points @romkatv. But I also think reality show(s)(ed) that some hubs will go away, even when some publishers are still pointing to them. So that leaves us with 2 evils:

• have subscriptions break
• find another way to redirect

Accpting that subscription break may be a good way of 'policing' things as subscribers will probably get in touch with publishers telling them to switch hubs.

[romkatv]

The problem of hubs disappearing is a real one. In general we can't expect the dead hubs to stay forever and do the redirects, so redirects in the protocol won't solve the problem completely.

A disappearing hub that wants to be nice should do the following:

1. Announce to its users that it's disappearing on a specific date. Use whatever channels of communication are available to reach the users.
2. Do not shutdown until that date.

That's the same protocol as I would expect from any decent service.

I forgot to mention another disadvantage of using redirects on a hub: publishers will have to repeat their full requests, including the payload, after seeing the redirect. That's wasteful.

[mterenzio]

Subscriptions should have to be renewed on a regular basis and clients should check to see that they have the current hub upon renewal.

[alkis]

Hub moves are like api endpoint moves. They should be handled with provider <-> developer communication and a (very) long deprecation time. This does not belong in the protocol itself but it is something each PuSH provider should handle on their own, given their resources and limitations.