Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP 201 is the correct response code for the authorization route #685

Open
rharriso opened this issue Jan 16, 2023 · 5 comments
Open

HTTP 201 is the correct response code for the authorization route #685

rharriso opened this issue Jan 16, 2023 · 5 comments

Comments

@rharriso
Copy link

rharriso commented Jan 16, 2023

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 in 201 responses.
  • Multiple web frameworks use 201 as the status code for successful POST 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.

rharriso added a commit to rharriso/pusher-js that referenced this issue Jan 16, 2023
@stale
Copy link

stale bot commented Apr 16, 2023

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.

@stale stale bot added the wontfix label Apr 16, 2023
@stale stale bot closed this as completed Apr 26, 2023
@benw-pusher benw-pusher reopened this May 26, 2023
@stale stale bot removed the wontfix label May 26, 2023
@benw-pusher
Copy link
Contributor

Thanks for raising this, I will escalate this internally for review.

@rharriso
Copy link
Author

Thanks @benw-pusher . For more context this caused an issue when integrating with nest js

@stale
Copy link

stale bot commented Sep 17, 2023

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.

@stale stale bot added the wontfix label Sep 17, 2023
@benw-pusher
Copy link
Contributor

Reopening as this is still pending review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants