Skip to content

fix: handle HTTP 304 response status code #4510

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

Merged
merged 1 commit into from
Apr 8, 2019

Conversation

rosen-vladimirov
Copy link
Contributor

In case 304 is returned, the cached version of the result should be used, so consider this response as success. NOTE: It can be returned only when specific header is sent in the request, so the caller actually expects to receive either 304 or 200 with new content.

PR Checklist

What is the current behavior?

Http requests returning 304 are considered as failed.

What is the new behavior?

Http requests returning 304 are considered as successful.

Fixes/Implements/Closes #[Issue Number].

In case 304 is returned, the cached version of the result should be used, so consider this response as success. NOTE: It can be returned only when specific header is sent in the request, so the caller actually expects to receive either 304 or 200 with new content.
@rosen-vladimirov rosen-vladimirov added this to the 5.3.2 milestone Apr 8, 2019
@rosen-vladimirov rosen-vladimirov self-assigned this Apr 8, 2019
@rosen-vladimirov rosen-vladimirov requested a review from Fatme April 8, 2019 08:29
@ghost ghost added the new PR label Apr 8, 2019
@cla-bot cla-bot bot added the cla: yes label Apr 8, 2019
@@ -168,7 +168,7 @@ export class HttpClient implements Server.IHttpClient {
this.setResponseResult(promiseActions, cleanupRequestData, { err: new Error(HttpClient.STUCK_RESPONSE_ERROR_MESSAGE) });
}
}, HttpClient.STUCK_RESPONSE_CHECK_INTERVAL);
const successful = helpers.isRequestSuccessful(responseData);
const successful = helpers.isRequestSuccessful(responseData) || responseData.statusCode === HttpStatusCodes.NOT_MODIFIED;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the check responseData.statusCode === HttpStatusCodes.NOT_MODIFIED should be inside isRequestSuccessful function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've considered this option, but I'm not sure if it is applicable for everyone who would use isRequestSuccessful helper method. By definition only requests between 200 and 300 are success, so it will seem strange to handle 304 inside that method

@rosen-vladimirov rosen-vladimirov merged commit 4aa3de6 into release Apr 8, 2019
@ghost ghost removed the new PR label Apr 8, 2019
@rosen-vladimirov rosen-vladimirov deleted the vladimirov/handle-http-304 branch April 8, 2019 09:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants