|Issue 36:||Better define the subscribe side of protocol, requirements it places on the hub||
1 of 41 Next ›
|8 people starred this issue and may be notified of changes.||Back to list|
SUMMARY: When verification fails, serve the requesting subscriber a 409. This lets them test the success of their own subscription. RELEVANT SECTION: 6.1 COMMENT/REQUEST: The reference hub implementation returns returns 409 if a subscription verification fails in sync mode. This is great and should probably be in the spec so there is a standard way subscribers (or subscriber agents) can know if verification failed. This would mean if they want to know, they would not use async mode.
Aug 4, 2009
Why 409 ("Conflict") rather than 403 ("Forbidden")?
Sep 3, 2009
Further questions that are related: From Mark Smith: > One thing I don't see in the spec is if a hub is required to persist > subscriptions to some data store. I can easily see someone > implementing an in-memory hub (I believe the Python Twisted > implementation a while back is like this) that doesn't save > subscriptions, and as a subscriber, we don't know that a hub has lost > our state or not. > > Is this something you intend to codify in the spec, or is it up to > particular hubs? (And in that case, what is the reference hub on > GAE's policy? If I specify 30 days as my lease, can I depend on that > actually working?) From Jeff Lindsay: > Anyway, I'm not entirely sure it's necessary for the spec, at least as a > requirement. It definitely needs to be stated clear if they are not > persistent in any implementation ... but this is an interesting issue. You > can definitely say an implementation needs to honor subscription lease, but > it can't honor it if it's not running... I think that's implied ... it's > interesting because most specs are about interfaces, not the state behind > them.
Summary: Better define the subscribe side of protocol, requirements it places on the hub
|► Sign in to add a comment|