search

ankurpiyush26 / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
1 stars 0 forks source link

Better define the subscribe side of protocol, requirements it places on the hub #36

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by bslatkin on 20 Jul 2009 at 6:32

GoogleCodeExporter commented 9 years ago 
Why 409 ("Conflict") rather than 403 ("Forbidden")?

Original comment by tonygarnockjones on 5 Aug 2009 at 12:05

GoogleCodeExporter commented 9 years ago 
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.

Original comment by bslatkin on 3 Sep 2009 at 6:50