Open rharriso opened 1 year ago
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.
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.
POST
requests as resulting in201
responses.201
as the status code for successfulPOST
requests.The justification in 2012 doesn't quite work for me. https://github.com/pusher/pusher-js/issues/17#issuecomment-76370378
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.