Do you understand the logic of HTTP 200 OK and HTTP 304 Not Modified

[JerryWang]

• Scenario1: the js file is accessed for the first time. No client or server side cache exists


• Scenario2: do not close the Chrome opened in scenario1, but directly click F5 to refresh


• Scenario3: Close Chrome and reopen it

This blog is written based on Fiori on-premise ( ABAP webserver used as gateway server ).

You might have observed for js resource request, there are different types of status response, 200 OK or 304 Not Modified.

We can use the following three scenarios to illustrate the difference.

Scenario1: the js file is accessed for the first time. No client or server side cache exists

Paste the following url into your Chrome and you could observe the http request below:

https://<host>:7080/sap/bc/ui5_ui5/ui2/ushell/resources/~20160308134900~/sap/fiori/core-min-0.js

You could see an HTTP 200 OK status code.

Where do the below highlighted HTTP response headers come from? How are they filled by server?

You can debug the following method in gateway server to get the answer.

1. line 9, the server tries to extract "last-modified" field from HTTP request which is not existing since this is the first request, so lv_modified_since is initial.

2. In my server, the last modified timestamp of JavaScript file core-min-0.js is 20160316205045, so variable lv_change_time_char and lv_change_time_string are filled accordingly.

3. Line 20 explains the reason how the first highlighted HTTP response field is filled.

4. The following two screenshots explain the logic where and how the left highlighted HTTP response fields are filled.

Scenario2: do not close the Chrome opened in scenario1, but directly click F5 to refresh

This time, instead of HTTP 200 OK, you get an HTTP 304 Not modified response:

Since you didn't close Chrome after you test scenario1, the cookie is reused and the more important point is the last modified timestamp returned by scenario1 as HTTP RESPONSE field is now used as the HTTP REQUEST field.

This time, server can successfully parsed this "If-Modified-Since" from HTTP request field. Please compare the screenshot below with the second screenshot of this blog.

Since now the last modified timestamp passed by Chrome is equal to the one got from server side, so HTTP 304 Not modified response field is set accordingly.

Scenario3: Close Chrome and reopen it

This time the core-min-0.js is directly retrieved from browser cache, since no "if-Modified-since" is appended in HTTP request field.

However, as you see the "last-modified" field is set in HTTP response field, so if you don't close Chrome and directly press F5, you will then again observe the HTTP 304 Not Modified response, just due to the same reason in scenario2.