HTTP 201 is the correct response code for the authorization route
Opened this issue · 5 comments
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
POSTrequests as resulting in201responses. - Multiple web frameworks use
201as the status code for successfulPOSTrequests.
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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you'd like this issue to stay open please leave a comment indicating how this issue is affecting you. Thank you.
Thanks for raising this, I will escalate this internally for review.
Thanks @benw-pusher . For more context this caused an issue when integrating with nest js
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you'd like this issue to stay open please leave a comment indicating how this issue is affecting you. Thank you.
Reopening as this is still pending review.