Description
This bug has been reported twice. Once in 2012 and again in 2016. The responses both times were essentially "201 is not the correct response code". This is against consensus.
- The MDN docs specifically call out successful
POST
requests as resulting in201
responses. - Multiple web frameworks use
201
as the status code for successfulPOST
requests.
The justification in 2012 doesn't quite work for me. #17 (comment)
We're not really creating a resource in the auth call, so it can't be referenced later.
Even if that is true (which I doubt since subsequent calls with the same input yield different responses), it's an implementation detail of the pusher backing service. It is not the semantic of API implementing the authentication route.
When a node application calls pusher.authorizeChannel
using the server library it appears to that a new authentication object was created.
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Fails unless server returns 200
What is the expected behavior?
Accept 201 as a valid response code for the authentication request.
**Which versions of Pusher, and which browsers / OS are affected by this issue?
All of them.