Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirections during (un)subscription POSTs to a hub #73

Closed
tonyg opened this issue Nov 29, 2016 · 12 comments
Closed

Redirections during (un)subscription POSTs to a hub #73

tonyg opened this issue Nov 29, 2016 · 12 comments
Assignees

Comments

@tonyg
Copy link
Contributor

tonyg commented Nov 29, 2016

The spec leaves unsaid how redirections resulting from an (un)subscription POST to a hub are to be treated. Perhaps (un)subscribers SHOULD follow a (small number of) redirections at this point in the protocol? (And hubs SHOULD use codes 307 or 308 to redirect.)

Example use case: sharding based on callback URL. A hub receives a subscription request, determines which hub is responsible for the callback URL supplied in it, and redirects the subscriber to that hub.

@julien51 julien51 self-assigned this Dec 6, 2016
@aaronpk
Copy link
Member

aaronpk commented Jan 10, 2017

It looks to me like the spec explicitly says that hubs must return HTTP 202. https://www.w3.org/TR/websub/#subscription-response-details so this kind of redirection response would not be allowed. The sharding you're talking about could be accomplished by having the hub forward on the subscription request itself to the backend, more like a typical web server load balancer setup. Would that not cover it?

@tonyg
Copy link
Contributor Author

tonyg commented Jan 10, 2017

Yes, that would be one way to achieve the effect. It requires quite a bit more machinery on the hub side, of course, but that seems OK.

More broadly, what if the hub moves? Shouldn't a 301 be applicable here? If so, then it seems a bit odd to permit only 301 and not other kinds of redirection.

@azaroth42
Copy link

Making 3XX a failure is, in my opinion, dangerous for sustainability of the service. If a hub or provider changes their infrastructure, they may not have any option but to change links. The rel=hub discovery link might not be easy to update ... meaning that the system would simply fail for no good reason.

Or ... what's the harm in allowing redirection at all stages in the protocol?

@julien51
Copy link
Collaborator

I my mind the use of "short" leases is the right solution around this and we should rely on redirects which could have different meanings/reasons to happen.

@azaroth42
Copy link

How would a short lease help you find where to go, if the topic resource has a broken hub link?

@julien51
Copy link
Collaborator

Since the lease is short, the subscriber has to perform the whole subscription dance again frequently... and will find the new hub.

@azaroth42
Copy link

if the topic resource has a broken hub link?

E.g. your short lease expires, you go to the topic resource to find the hub, it sends you to the wrong place which can't redirect you anywhere and you fall off the end.

@aaronpk
Copy link
Member

aaronpk commented Feb 13, 2017

In the history of PubSubHubbub, there hasn't been any actual need for the hub to change its hub URL. The hubs that have been publicly available have been at the same URL for their entire lifetime over many years. This feels like finding a solution to a theoretical problem.

@aaronpk aaronpk assigned aaronpk and unassigned julien51 Mar 28, 2017
@julien51
Copy link
Collaborator

PROPOSAL (aaronpk): add language to make it expliciti that 307/308 are supported and that we hence support hub-redirects
-> resolved

aaronpk added a commit that referenced this issue Mar 30, 2017
Hub supports redirect to another hub. Fixes #73
@aaronpk aaronpk reopened this Mar 30, 2017
@aaronpk
Copy link
Member

aaronpk commented Mar 30, 2017

@tonyg we discussed this with the group, and realized that the spec previously didn't explicitly disallow supporting 307/308 redirects, so we decided to make it explicit that it is supported. Please take a look at the new language and close the issue if you're satisfied! Thanks! https://w3c.github.io/websub/#subscription-response-details

@azaroth42
Copy link

👍 to allowing 307,308 Thanks for being open here!

@tonyg
Copy link
Contributor Author

tonyg commented Mar 30, 2017

👍 Looks good to me! Thanks, @aaronpk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants