Use POST instead of GET for subscription denials
crertel opened this issue · comments
From section 4.2 of the spec:
If (and when), the subscription is denied, the hub MUST inform the subscriber by sending an HTTP [RFC7231] GET request to the subscriber's callback URL as given in the subscription request.
GET requests are typically intended to be used to fetch documents--notifications such as this are generally done with POST.
Encoding the arguments in a query string seems a bit inelegant compared to just using the POST forms we're all used to--least of all because topics and reasons might result in a large and/or malformed URL.
I wonder if things like verification-of-intent might also be better as POST rather than GET? Essentially all uses of a callback should likely be more POST than GET, it seems to me!
Quite right!
I'm a bit new to the spec, but one thing I am a bit curious about is the heavy use of webhooks for many things--for example, it would seem that getting a quick denial on a subscription via normal HTTP return codes would be simpler than have a webhook to callback to.
Then again, that's a rather invasive change if existing systems are set up otherwise; I'm just curious what the reasoning for it is.
That does seem reasonable to have all the web hooks be POST request, it's too bad it's a completely breaking change though.
I believe the motivation for the webhook on the subscription request is to allow for asynchronous verification of the subscription. Kind of like approving a friend request on Facebook, where you don't see their stuff until after the friend request is accepted. Since an actual person sees the request and clicks confirm, there might be a considerable delay.
@aaronpk ah, that makes sense!
That said, in terms of breaking change--the existing behavior is pretty obviously wrong from any sort of best-practice folks've had for years. It shouldn't be difficult to fix for anybody so inclined--the spec should outlast incorrect implementations.
I'm not advocating for "let's go REST" or anything extreme like that: I'm just saying that we should be using HTTP as its been intended to be used for two decades.
Yeah I'm not opposed to that change. Let's wait for some more folks to chime in here.
Sounds good to me!
One nice thing about the switch is that backwards compatibility is straightforward, where desired: callbacks that want to interoperate with PSHB 0.3/0.4 can continue to accept GET at the same time as accepting W3C-PubSub POSTs. Conversely, hubs can try POST first, and if they get 405, can retry with GET if they like.
Is there any benefit in this change apart from elegance? Would like there to be a more substantial and proven benefit to break backwards compatibility. Also would like someone to actually do some digging and try to find the original discussions around why it came to be a GET rather than a POST. There might have been good arguments for that back in the days and ignoring them just because the same people might not be active here and now also seems like a waste.
I am not sure this is a great change. I understand and agree with the 'elegance' point of view, but I really want to differentiate notifications form the the "handshake". I think doing that on the verb is convenient.
Oh my gosh. It hadn't clicked that GET vs POST was the only way of distinguishing the two, but now I remember that I thought this was gross way back in 2009. Looking at the RabbitHub code, it seems I dispatch not only on the HTTP method but on whatever the value of hub.mode in the URL query string is. Eww :-)
Since we're adding headers (link rel...) to the POSTs that deliver content, is it worth considering:
- using POSTs to callbacks uniformly
- adding
hub-actionheader to verification-of-intent POSTs, with valueverify-subscription-change - omitting
hub-actionheader from notification POSTs
?
It is still backwards compatible in that PSHB 0.4 notifications look the same and PSHB 0.4 verifications look the same, but W3 PubSub verifications look different.
(There don't seem to be any really nice options I can think of. Using GET as the spec does now is kind of icky, adding a new header makes me a bit nervous though I can't explain why, and using weirdo ideas like PUT for subscription verification and DELETE for unsubscription verification is just wrong...)
I think having a clear distinction on the method will never be liked by the REST people but it has the benefit of being consistent :)
A REST supporter is watching this discussion 😄
"but I really want to differentiate notifications form the the "handshake"."
Having different webhooks to allow out-of-band communication of events, or having additional headers (ew), would accomplish this without violating basic HTTP hygiene.
" I think doing that on the verb is convenient."
Specs need to be more than convenient--they need to encode best practices. Using a GET to do what is in effect creating a subscription denial object is not best practice, and hasn't been for a loooong time. GET requests should generally never mutate state on the server handling them.
Again, this isn't so much a REST thing--that's a paradigm that I don't think is super applicable here!--but just an HTTP thing. Similar to sorting out the correct HTTP status codes, but that's a problem for another day. :)
@voxpelli @tonyg @julien51 : A more general question--we've seen some questions about backwards compatibility here--how widely deployed is this, exactly? We should probably make sure our conservatism is in proper measure to the installed user base.
@crertel PubSubHubbub is used by Google (for example https://developers.google.com/youtube/v3/guides/push_notifications), WordPress.com (https://en.support.wordpress.com/pubsubhubbub/) and a bunch of other big players: https://github.com/pubsubhubbub/PubSubHubbub/wiki/Companies-Using-PubSubHubbub.
@crertel Also used by Google when accepting feeds as site maps: https://webmasters.googleblog.com/2014/10/best-practices-for-xml-sitemaps-rssatom.html Eg. Medium which just bought Superfeedr is also using PuSH. Blogger and WordPress.com as well + many plugins for open source blog systems and CMS:es.
Even GitHub claims to support it: https://developer.github.com/v3/repos/hooks/#pubsubhubbub
Most feed readers are also using it. See this status post from two years ago: https://blog.superfeedr.com/state-of-pubsubhubbub/ Since then also eg. Feedbin has added support for it: https://feedbin.com/blog/2013/12/03/pubsubhubbub/
Basically – it's been the best practice for at least everyone who publishes feeds for many many years and it's thus a very widely deployed standard.
Closing for now.
What does "Closing for now" mean? Did the WG decide to close this issue?
We did talk about this in the last F2F meeting. The conclusion was that while using GET vs POST to differentiate between notification delivery and control operations is not "restful" or necessarily best practices, it does make the implementations easier. (Not to mention that it's been part of the spec for a long time and is widely deployed).
Some notes from the discussion: https://www.w3.org/wiki/Socialwg/2016-11-17-minutes#PubSub
As discussed in the meeting, I've submitted a PR to add an explicit clarification of this spec's use of GET vs POST: #63
@crertel Does the paragraph added in https://github.com/w3c/websub/pull/63/files make it clear the motivations for using GET/POST this way?
@aaronpk the writing seems clearly-worded and explains the reasoning behind it, at least as far as I can tell.
Hi, sorry for waking this from the dead, but we're facing a similar discussion in the HL7 FHIRcast (health care context synchronization based on WebSub) standardization. The issue that was brought up there, was that the length of the URL can be a problem with GET and some web servers. Did you ever consider this when discussing GET vs. POST? For example, making e.g. the hub.reason field too long might prevent the subscriber from getting the denial request.
@aaronpk, not sure if you're the correct person to tag, but did you ever talk about the length of the GET URL during the WG meeting (see my comment above)? Is this something you might consider bringing up for discussion and do you have any other comments on this issue?