How to cache an HTTP response indefinitely - javascript

How do I send an HTTP response that any client would cache forever (or until its cache is cleared), such that when the browser needs that resource, it makes no HTTP request and instead retrieves the HTTP response from the local file system?
Usage note: this is for versioned client code in an Ajax application. Everything is accessed through the uncacheable example.com/front.htm, which merely contains a script tag linking to example.com/currentversion/bootstrap.js which is cached indefinitely. Because the uncacheable HTML file determines the current version, there is no need for the client to update scripts.

According to the RFC, "to mark a response as 'never expires,' an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21.
I don't know what the reasoning behind the one-year limitation is, so take it for what it is.

Cache until 2038. You can't go any farther than that (reliably) because of the 32-bit Unix Epoch bug. Use this header:
Expires: Sun, 17 Jan 2038 19:14:07 GMT

Related

does javascript files get requested again from the server on page refresh?

I don't know how to ask this question but, i am developing a single page application(SPA) using nodejs on the server side and whenever the data gets updated the user gets informed, however if the user has refreshed wouldn't the json data and every script file just vanish an get requested from the server again?
How can i prevent the javascript files and specifically the file that has the json data from being requested again on page refresh?
is there a way to solve this problem?
JavaScript files are not special. Just like images, style sheets, and HTML files, they get re-requested as necessary by the browser.
And so the same techniques for minimizing re-retrieval of them apply. The browser can reuse its cached copy of the file if you configure your web server to set appropriate caching headers when responding with the file data (provided the browser still has a copy).
You can see an example of this on the Google Libraries site. If you request a specific version of a library file (say, jQuery 1.10.1) when your web console open to the network tab, you'll see that Google returns it with these headers (irrelevant ones omitted):
Age: 238894
Cache-Control: public, max-age=31536000
Date: Thu, 09 Jan 2014 20:47:08 GMT
Expires: Fri, 09 Jan 2015 20:47:08 GMT
Last-Modified: Tue, 09 Jul 2013 11:31:25 GMT
Note that the file is allowed to be cached, without revalidation, for a year. So if the user refreshes the page, the browser can reuse its cached copy (if it has one). (This is not what Google does if you use one of the wildcard "any version of jQuery 1.10" URLs, because of course the tip version changes...)
Some browsers may bypass their cache with a refresh (particularly a "force" refresh like Ctrl+F5). In that case, they may at least send an If-Modified-Since request.
If you want to prevent cache and reload javascript at every request, make suer you use the correct header:
Cache-Control:max-age=0
Your browser will undertand to refresh all resources at every request.
For a better understanding about cache, please give a look at this A/Q
As for json data, you can save it in local storage (http://www.w3schools.com/html/html5_webstorage.asp)
Perhaps you can try Application Cache and Local storage.

Setting the timeout when using Dojo

I recently updated an app that uses Dojo to sent asynchronous petitions to my server which serves these petitions with cgi.
My problem is as follows. So for example the variable that makes the requests is
parent.sc_dojo.io.script.jsonp_sc_dojoIoScript2
This new service takes too long to send the response approximately 40 - 60 seconds, and after this time the variable parent.sc_dojo.io.script.jsonp_sc_dojoIoScript2 appears as UNDEFINED
I made an analysis using firebug, see the following image for major details.
The petition to the server has the following data:
Connection Keep-Alive
Content-Type text/javascript; charset=utf-8
Date Tue, 10 Sep 2013 12:39:22 GMT
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Ubuntu)
Transfer-Encoding chunked
The timeout ranges from 5 to 100, I don't really know the units of this measure, Any ideas?
About Connection Keep-Alive
When a client browser sends the "Connection: Keep-alive" header to an HTTP/1.1 server, the browser is saying "hey, I want to carry on a long conversation, so don't close the connection after the first exchange."
The keep-alive "timeout" value is in seconds. The "max" value is unit-less, representing the maximum number of requests to service per connection. Taken together, these augment the client's request to "hey, I want to carry on a long conversation, so don't close the connection after the first exchange BUT if nothing exchanges in 5 seconds (timeout) OR if more than 100 requests go back and forth (max), I'm ok with you closing the connection." The server responds with the actual values it will service for timeout and max.
The penalty for a closed connection is that a new one has to be opened up. Some modern browsers limit the number of simultaneous open connections, so keeping these values too small may introduce latency (while your app waits for free connections). On the other hand, the server need not agree to the timeout and max values requested: the server sets its own limits.
See these articles for details:
http://www.feedthebot.com/pagespeed/keep-alive.html
http://en.wikipedia.org/wiki/HTTP_persistent_connection
http://www.hpl.hp.com/personal/ange/archives/archives-95/http-wg-archive/1661.html
About dojo timeouts
I don't see your code or dojo version, but dojo does allow you to set how long it will wait for a response via the timeout property in the XHR request. The default timeout is "never". Code below.
In practice, "never" is misleading: browsers have their own defaults for keep-alive timeouts and upstream routers might have their own timeouts.
Try to keep it short. If the response takes more than 15 seconds, there may need to be a different design approach to the problem: reverse ajax, polling, combined response, etc.
require(['dojo/request/xhr'], function (xhr) {
xhr(
'http://www.example.com/echo',
{ timeout:15000 /* change this, units are milliseconds */, handleAs:'json' }
).then(function (r) {
console.log(r);
});
});
The specific problem
Ok, finally. If you have a long server side run, here's what I would do:
Send a request from client to server that starts the job
Server responds with a unique URL that can be polled for status
In Javascript, use setInterval() to periodically check the returned URL for status
When the URL shows "status" done, kill the setInterval and issue a final call to get the result

Forcing AJAX request to revalidate cache with server, without reloading completely

I have a web application that lets the browser cache AJAX requests result for a long time. I have found out how to make a request that bypasses the cache entirely, when probable modifications are detected. But I would want to let the user trigger a data refresh.
In this scenario, I'd like the browser to check with the server if the cache is stalled but use it if it is not (that is, if the server responds with a 304 code). The goal is to spare the loading time because the data is huge.
The server includes the following headers in all responses:
Cache-Control: private, max-age=604800
Last-Modified: ... # actual last modification date
I managed to burst the cached object entirely in Chrome (not tested other browsers yet) by using the following HTTP headers in the request:
Cache-Control: max-age=0
If-Last-Modified: Tue, 01 Jan 1970 01:00:00 +0100
The If-Last-Modified line is the one that really has an effect. Chrome seems to ignore the Cache-Control header in the request.
I have also found that using Cache-Control: must-revalidate in the server response forces the browser to validate its cache with the server for each request.
But is there any way to revalidate for just one precise request, decided on the client-side?
Note that I'm not specially attached to doing this with HTTP headers, so any other method that I would not be aware of is welcome!
you can add a url parameter which value base on time to clean cache for just one precise request.
$.ajax({
url:"/questions?nocache="+Date.now(),
"success":function(data){
console.log(data);
}
});

Get time from time.nist.gov NTP server using JavaScript?

How to do? I am a beginner coder - full references and code would help. I literally spent like 5 hours trying to find a solution to this - there are some references online but nothing works! And I don't have access to the NTP server and yes I have to use a public server - such as time.nist.gov.
Help!!!
Short answer:
Not doable.
Long answer:
Even if cross-origin policy would allow it, there's no way to get NTP directly via Ajax without PHP (or something) relaying your request. First reason is that time servers normally stay on UDP port 123; there's no way for Ajax to do UDP; if that's not enough, when Ajax sends a request to a server, it expects to see in response some HTTP headers, some status codes, a response body, etc. NTP doesn't keep that structure, it only sends a string. And there is no raw socket connection support in HTML5 either.
But what you can do with Ajax is look at the request headers because most responses come back with a header that looks like this:
Date:Mon, 21 May 2012 15:30:58 GMT
And there's your time.

Removing HTTP headers from an XMLHttpRequest

I am working on an ajax long polling type application, and I would like to minimize the amount of bandwidth I am using. One of the big costs right now are the client side HTTP headers. Once I have a connection established and a session id stored on the client, I don't really want to squander any more bandwidth transferring redundant http information (such as browser type, accept encodings, etc.). Over the course of many connections, this quickly adds up to a lot of data!
I would really like to just take my XMLHttpRequest and nuke all of the headers so that only the absolute minimum gets transmitted to the server. Is it possible to do this?
You have very little control over request headers, but you can still do a few things -
Reduce the size of the cookie. In general, you only want the session id, everything else can be eliminated and stored server side.
Minimize http referrer by keeping a short URL. The longer your page url, the more data will have to be sent via the http referrer. One trick is to store data in the fragment identifier (the portion of the url after the #). The fragment identifier is never sent to the server, so you save a few bytes over there.
Some request headers are only sent if you had previous set corresponding response headers. For example, you can indirectly control the ETag and if-modified-since request headers.
You may want to consider Web Sockets. Support is pretty good (IE10+).
You may be able to override some of the standard headers using setRequestHeader() before sending the request, but it is possible the browser may not allow overriding of some and it seems there is no way to get a list of headers (besides asking the server to echo them back to you) to know which to try to override.
I think it's possible to remove all headers at least in some browsers.
Take a look at the communication between gmail/calendar apps and the backend from google in chrome (it's not the same in firefox)
it's possible google has some hidden api for the XMLHttpRequest object,
you'll see something like the below output (notice there is no request headers section):
Request URL:https://mail.google.com/mail/u/0/channel/bind?XXXXXXXXXXXXXX
Request Method:POST
Status Code:200 OK
Query String Parameters
OSID:XXXXXXXXXXXXX
OAID:XXXXXXXXX
VER:8
at:XXXXXXXXXXXXXX
it:30
SID:XXXXXXXXXXXX
RID:XXXXXXXXX
AID:XXXXXXXXXX
zx:XXXXXXXXXXXX
t:1
Request Payload
count=1&ofs=211&req0_type=cf&req0_focused=1&req0__sc=c
Response Headers
cache-control:no-cache, no-store, max-age=0, must-revalidate
content-encoding:gzip
content-type:text/plain; charset=utf-8
date:Tue, 09 Oct 2012 08:52:46 GMT
expires:Fri, 01 Jan 1990 00:00:00 GMT
pragma:no-cache
server:GSE
status:200 OK
version:HTTP/1.1
x-content-type-options:nosniff
x-xss-protection:1; mode=block

Categories

Resources