We Keep Coding

Check file checksum before deciding to download

I want to implement the following logic: fetch the big file (up to 100MB) and store it in the service worker. Then I want to check periodically (say once per hour) and if the remote file changes - need to re-download it.
Otherwise - I don't want to disturb the server.
I was thinking about sending something like 'OPTIONS' request, just to get checksum of the file.
How could I tackle this?

Use HTTP Conditional Requests. Here's a way you could implement this:
Configure the server to include a Last-Modified response header with the date when the requested file was last modified and to respond with 304 Not Modified if the file was not modified since the date indicated by the If-Modified-Since request header.
Make the service worker save the value of the Last-Modified header and use it in the next requests to the file. If the server returns a 304 Not Modified, it means that the cached file is still up-to-date. If the server returns 200 OK, cache that file and store the value of the Last-Modified header.
You can also use ETags with If-None-Match.
This is the standard way to handle caching with HTTP.

Looking at how imgur serves its images. How come when I check network tab in Chrome, its sending this PNG and its only 387B? [duplicate]

I'm using the Google "Page Speed" plug-in for Firefox to access my web site.
Some of the components on my page is indicated as HTTP status:
200
200 (cache)
304
By Google's "Page Speed".
What I'm confused about is the difference between 200 (cache) and 304.
I've refreshed the page multiple times (but have not cleared my cache) and it always seems that my favicon.ico and a few images are status=200 (cache) while some other images are http status 304.
I don't understand why the difference.
UPDATE:
Using Google "Page Speed", I receive a "200 (cache)" for http://example.com/favicon.ico as well as http://cdn.example.com/js/ga.js
But, I receive a http status "304" for http://cdn.example.com/js/combined.min.js
I don't understand why I have two JavaScript files located in the same directory /js/, one returning a http status 304 and the other returning a 200 (cache) status code.

The items with code "200 (cache)" were fulfilled directly from your browser cache, meaning that the original requests for the items were returned with headers indicating that the browser could cache them (e.g. future-dated Expires or Cache-Control: max-age headers), and that at the time you triggered the new request, those cached objects were still stored in local cache and had not yet expired.
304s, on the other hand, are the response of the server after the browser has checked if a file was modified since the last version it had cached (the answer being "no").
For most optimal web performance, you're best off setting a far-future Expires: or Cache-Control: max-age header for all assets, and then when an asset needs to be changed, changing the actual filename of the asset or appending a version string to requests for that asset. This eliminates the need for any request to be made unless the asset has definitely changed from the version in cache (no need for that 304 response). Google has more details on correct use of long-term caching.

200 (cache) means Firefox is simply using the locally cached version. This is the fastest because no request to the Web server is made.
304 means Firefox is sending a "If-Modified-Since" conditional request to the Web server. If the file has not been updated since the date sent by the browser, the Web server returns a 304 response which essentially tells Firefox to use its cached version. It is not as fast as 200 (cache) because the request is still sent to the Web server, but the server doesn't have to send the contents of the file.
To your last question, I don't know why the two JavaScript files in the same directory are returning different results.

This threw me for a long time too. The first thing I'd verify is that you're not reloading the page by clicking the refresh button, that will always issue a conditional request for resources and will return 304s for many of the page elements. Instead go up to the url bar select the page and hit enter as if you had just typed in the same URL again, that will give you a better indicator of what's being cached properly. This article does a great job explaining the difference between conditional and unconditional requests and how the refresh button affects them:
http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx

HTTP 304 is "not modified". Your web server is basically telling the browser "this file hasn't changed since the last time you requested it." Whereas an HTTP 200 is telling the browser "here is a successful response" - which should be returned when it's either the first time your browser is accessing the file or the first time a modified copy is being accessed.
For more info on status codes check out http://en.wikipedia.org/wiki/List_of_HTTP_status_codes.

For your last question, why ? I'll try to explain with what I know
A brief explanation of those three status codes in layman's terms.
200 - success (browser requests and get file from server)
If caching is enabled in the server
200 (from memory cache) - file found in browser, so browser is not going request from server
304 - browser request a file but it is rejected by server
For some files browser is deciding to request from server and for some it's deciding to read from stored (cached) files. Why is this ? Every files has an expiry date, so
If a file is not expired then the browser will use from cache (200 cache).
If file is expired, browser requests server for a file. Server check file in both places (browser and server). If same file found, server refuses the request. As per protocol browser uses existing file.
look at this nginx configuration
location / {
add_header Cache-Control must-revalidate;
expires 60;
etag on;
...
}
Here the expiry is set to 60 seconds, so all static files are cached for 60 seconds. So if u request a file again within 60 seconds browser will read from memory (200 memory). If u request after 60 seconds browser will request server (304).
I assumed that the file is not changed after 60 seconds, in that case you would get 200 (ie, updated file will be fetched from server).
So, if the servers are configured with different expiring and caching headers (policies), the status may differ.
In your case you are using cdn, the main purpose of cdn is high availability and fast delivery. Therefore they use multiple servers. Even though it seems like files are in same directory, cdn might use multiple servers to provide u content, if those servers have different configurations. Then these status can change. Hope it helps.

Execution order of Http Response headers?

I saw this plugin which download files using Ajax and some other fallback techniques.
But since ajax download file feature is not supported in all browsers , he used a trick with Iframe. ( which is pretty easy to implement)
But one thing caught my eye :
He also added an option which tells you when the file has finished
download.
He did it via cookie. He polls to see if the cookie via setInterval. as long as the cookie does not exist - the file wasn't finish download.( and when the cookie is present - the file has downloaded)
So the header for downloading a file is:
Content-Disposition: attachment; filename=Report0.pdf
And he added :
Set-Cookie: fileDownload=true; path=/
But then I thought - who said that set-cookie is called after the file has finish downloaded ?
Questions:
Looking at the actual headers :
1 - Does the browser digest each header according to the actual order of appearance ?
2 - Are there any headers which must appear prior to other headers ?
3 - Does the digest of each header - blocks the digest until current hedare digest is completed ? I mean : does the line content-disposition:attachment;filename=1.jpg prevents the browser from digesting the next header - until the filename=1.jpg is finished loading ?
nb
I've also tried investigate it via fiddler but I didn't get any conclusion.( I mean how can I test it in fiddler ?)

You're right to be skeptical.
There's no requirement that a client wait until the response body is complete to evaluate the Set-Cookie header that preceded the body, and there's in fact good reason to believe that most browsers will set the cookie before the body is complete (since many web pages will look at document.cookie in JavaScript inside a HTML page).
In fact, I tested this (using a MeddlerScript you can see here: http://pastebin.com/SUwCFyxS) and found that IE, Chrome and Firefox all set the cookie before the download completes, and set the cookie even if the user hits "Cancel" on the download.
The HTTP specification includes the notion of a Trailer (which is a header that appears after the response body) but these are little used and not supported in many clients (e.g. WinINET/IE). If the client did support Trailers, the server could send the Set-Cookie header after the body which would mean that the client couldn't see it until the body finished downloading.

Ajax Request header keep alive

I have Ajax request to update the client page if any new data is available to server.I have set the connection 'keep-Alive' So here I am not making new Ajax call every time to check the updated data. I have callback which update the page if any records is available.
Below is my Ajax Request.
xmlRequest.open("post", url, true);
xmlRequest.setRequestHeader("Connection", "Keep-Alive");
xmlRequest.setRequestHeader("Content-Type","application/x-www-form-urlencoded;");
xmlRequest.send(some data);
It works fine, but if user refresh the browser then, Ajax does not get the updated data from server.
My concept is not very clear on how the connection type "keep-Alive" works. but it seems when user refresh the browser then Ajax connection lost to the server hence Ajax stopped listing.
I know i can fix this by making new call whenever browser refresh the page. but here i want to understand does it really Ajax keep-Alive lose the connection when browser refresh.

The javascript environment normally gets cleared on page reset, but you can use window.localStorage to persist across refresh and maintain your xmlRequest variable. You should then be able to test client + server side together to see if it is necessary to re-initialize the connection.

Let's first try to understand what does Keep-alive mean it means: the server won't close the Connection after fulfilling the request
So hence your sent the requet to the server, and server sent the response back to your browser, now in that case the request will not closed the server will keep the connection open so for every new request you send to server same requet object will be used.
So when you refresh your page the client/browser lost the connection so I think the best solution is to promot your users do not refresh page like it happen when we making transactions.
If you save your connection object to Browser storage this can not be useable!
Thanks
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive
Keep Ajax alive
https://reqbin.com/req/javascript/4sa9kqvu/keep-alive-connection-example#:~:text=Keep%2DAlive%20Connection%20Example%20%5BJavaScript,considered%20persistent%20unless%20declared%20otherwise.

How to tell if new location is forcing file download?

I am redirecting user using window.location.href to a page that forces a file download using the following headers:
Content-Description: File Transfer
Content-Disposition: attachment; filename="foo"
As a result, user is not taken to the page, though asked if he wishes to proceed downloading the file.
How do I tell when the response from the server is received?
The user flow that I am trying to achieve:
Display loader.
"redirect" the user (with window.location.href).
Hide loader when response is received.

From your client side code, also pass an generated ID to the server, asking it to set a cookie for you to that value.
Your server side code should pass the cookie back with the downloaded file (in the HTTP headers).
Then you can poll for the cookie in your javascript after the redirect to see when the server has responded with a successful connection.