Salmon should accept 200, 201 and 202, not just 202

[Max Ogden]

In terms of HTTP response codes, Salmon shouldn't care whether or not it receives back a 200, 201 or 202 response. 

From the spec:

"The server MAY provisionally accept the salmon at this point and return a 202 Accepted response. This allows the server to perform the subsequent steps asynchronously."

This assumes that the server is going to complete the request asynchronously. If the server actually completes the request synchronously it has to lie and return 202 even though the accurate response would be 200/201.

This came to my attention as I was implementing Salmon on CouchDB. In Couch there is a synchronous document storage handler that you could configure to accept and store Salmon updates. Because it is synchronous (from the Couch docs:) "the status code for an update function response is hardcoded to be 200/201 unless an error occurs."[source]

Thanks,

Max Ogden 

[John Panzer]

The client should not care in terms of recording a success or failure.  The "MAY" basically is a warning to the client that the server is free to do this - it is not a requirement on the server to use a 202 (that would be a "MUST").  The note is actually intended to act as a nudge to clients that they should be prepared to accept any 2xx response, not just 200/201.  Perhaps it could be more clearly worded?

(The major important difference between 200/201 and 202 is that a client won't expect to see any side effects immediately after a 202 is received -- so a server can safely respond with a 202 no matter what; it's not obligated to make effects available synchronously.  On the other hand, it's not actually promising any delay either, so if the side effects are visible it's not a problem.)

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Max Ogden]

"The note is actually intended to act as a nudge to clients that they should be prepared to accept any 2xx response, not just 200/201.  Perhaps it could be more clearly worded?"

That seems like a good idea. Earlier I was testing OStatus integration with Identi.ca and when you add a remote feed from Identi.ca, the Status.net code will immediately send you a Salmon 'follow' notification using the newest signature salting algorithms. If they don't immediately receive a 202 they will assume your server didn't correctly parse it and that you are running the older sig crypto algorithms, so they will send a duplicate message using the older salting. There is no difference between the two notifications other than the signature and a 200/201 doesn't prevent the second update from being sent, presumably due to the unclear wording in the spec.

Possible solutions could be that they could either accept 2xx or there could be some sort of protocol version in the body of the XML.

Thanks,

Max