vlki
commented
5 years ago Hello @juliencampion , thanks for taking the time to explain! I did not know about this problem and it makes perfect sense that in your scenario the exception returned should have error code 500, not 401. I would appreciate if you could post a pull request.
juliencampion
Thank you for this module ! Unfortunately I've encountered a problem while using it.
Description: We assume an API endpoint that returns an error (e.g. 500, Internal server error) instead of a 2xx response, when processing the request, but only after authentication is done. We also assume that a request must be made to this endpoint, but our token has expired, so it needs to be refreshed beforehand. We also assume that the sample code from the
README.mdfile is used to make this request.Thus, a call to
fetch('/api/data')triggers the following HTTP requests:GET /api/data: returns 401 Unauthorized, and throws an exception in the client codePOST /api/refresh-token: returns 201 Created, and a new token is retrievedGET /api/data: returns 500 Internal Server Error, and throws a second exception in the client codeExpected behavior: Upon encountering such a scenario, this call to
fetch('/api/data')should throw the second exception, the one resulting from the response with 500 HTTP status code.Actual behavior: The actual exception raised from the call is the first one, the one resulting from the response with 401 HTTP status code, instead of the second one. This means that the developer handling this exception is confused from such an exception, since having expired tokens is expected to be a common occurrence, and furthermore the token was refreshed successfully in this example.
I encountered such a problem earlier. If you need help fixing it or have other priorities, I can submit a pull request to this repository, addressing this issue.
Thank you for your time!