I recently received a request to determine if a user's browser has pre-fetching enabled. I've searched around, but I've come up empty. Any thoughts on how to accomplish this task? I've watched traffic in the header and I don't see anything in the request that would indicate pre-fetching has been enabled.
Put <link href="myTester.xxx" rel="prefetch" /> in the head.
In whatever handles for myTester.xxx (which would hence more likely by myTester.php, myTester.aspx, etc.) set a flag in the session (if you're already using sessions and hence there's no more penalty for doing so) or set a cookie. Make the response v. small (empty would be fine).
On onload, set a delayed (use setTimeout) attempt to retrieve an XML or JSON file from myTesterResult.xxx which has a different result depending upon that session value or cookie.
Alternatively, if you don't need it to be reacted to on that page, there's no need for any client-side script at all, subsequent server-side script will be able to use the session or cookie as appropriate.
I'll 2nd the opinion that the client probably can't do it. One possible solution is to add a prefetch to a page that signifies pre-fetching is enabled, e.g.:
<link rel="prefetch" href="/hasPrefetching.php">
If you need to know on the server, you now have the info. If you need to know on the client, you can poll for it after a while.
Related
I am new to javascript and webtechnology. I have a requirement, where I have to change the lang attribute of
<html lang="en-US">
in webpage numbers of time, and then reload the page. I have designed an chrome-extension that changes lang attribute of current tab page, it is working well, but it doesn't fetches the correct Resource files as per the locale changed. It only changes lang of page in cache.
I want to know, is there any way I can basically load the page with different lang code without actually changing the source code manually ?
Can we pass a javascript like document.documentElement.lang="ab-CD" as webRequest and then load the page
Please help..
No, you can't do this entirely client-side. You have to do something to tell the server what language to use, and then the server has to send back the HTML page with the appropriate content.
One thing you can do (or rather, the browser can do) to tell the server what language to send back is to send the Accept-Language header in the HTTP request for the resource, identifying the desired language. But unless you're doing an ajax request, you can't set that header from client-side code, the browser sets it.
If you want to let the user decide the language, the simplest thing is probably to have different paths for different languages, or a query string parameter. Your server-side code would use the query-string parameter or, if none, the Accept-Language header.
When a visitor visits http://www.yourwebpage.com/
Is there a way to have the browser use the previously cached response? Or will it always make a request to the server?
I am guessing a request to the server will occur, but is then possible to respond with an empty string, and let the browser automatically use the cached response for index.html? Or do you always have to supply the entire answer?
The question is related to how much the initial index.html response for a JS based application should contain or if the index.html response should make a second request for html pieces and such.
// Example: Pseudo code
<html> ...
<script>
if ( !localStorage.index ) {
localStorage.index = loadFromServer( 'head.html' )
}
document.head.append(localStorage.index);
</script>
...</html>
The question boils down to, if i have ten templates.html files, which I would like to serve once, should they be included in the index.html response or should another request be made to fetch these as one bundle.
Obviously, if I make a second request, the browser will cache that response if proper headers are set, but that would cost another request, at least the first time.
If I include them in the index.html then the initial response will be bigger, but less than the two requests otherwise necessary, but how will subsequent requests to fetch the index.html be treated?
I have never visited a page who do not load something, although teoretically if the proper cached-headers from previous request has been set properly, it should be possible to treat it as an offline application, or is cache now applicable for initial requests? Only for requests made for instance by ajax or
Is the last statement true?
Basically, could you execute JavaScript by visiting a webpage using only cached data, that is without actually needing to make any request, or at least wait for an answer.
Is this possible? Perhaps storing the entire index.html in the localStorage is one way and have the index.html response the second time respond with only a script tag saying load from localStorage.
EDIT 1
I have come to understand that there is something called a Manifest for at least Firefox which can allow for the treatment as such as an application install the first time. https://developer.mozilla.org/en-US/Apps/Build/Manifest
Yes, your web server (and/or web app framework) should use cache headers to give this sort of instruction to the browser. Cache headers include etags and cache-control. A full example and explanation is here: https://www.mnot.net/cache_docs/#CACHE-CONTROL
But basically, those tell the browser when to consider the fetched content stale, when to actually make a request. Further, if the server knows the information hasn't been changed, it will respond with a HTTP 304 response, which will result in the client using the cached copy instead as well.
You really don't need to use the localstorage option unless you want your JS to definitely never ask the server for something unless it's not in localstorage. The problem with that is that you then have to manage your own cache invalidation, etc.
I am using in the same page <script src="xxx.js?hi=1" ></script>
and <script src="xxx.js" ></script>
Problem is, in the script itself when i ask for the params, i dont see the hi=1 even though it sent it... can it be cache??
thank you!
from my experience, the browser should load the script twice... but when you say the script doesn't see the hi=1, you do mean the script on the server, right? Because the Javascript returned won't be able to see that. It is the server side that gets the request to send back any content that sees it. So in your PHP or whatever language you are using on the server side, print out the params, and you should be able to see it.
And you can "spit out" different Javascript content depending on the params that the server script sees.
No. Different URIs are different URIs, the browser doesn't cache if the difference is only in the query string. This won't be a caching issue.
The problem is most likely either in how you try to access the query string, or that you use globals in the script and the two copies are overwriting each other's data.
Let's say I have a page that refers to a .js file. In that file I have the following code that sets the value of a variable:
var foo;
function bar()
{
foo = //some value generated by some type of user input
}
bar();
Now I'd like to be able to navigate to another page that refers to the same script, and have this variable retain the value set by bar(). What's the best way to transport the value of this variable, assuming the script will be running anew once I arrive on the next page?
You can use cookies.
Cookies were originally invented by
Netscape to give 'memory' to web
servers and browsers. The HTTP
protocol, which arranges for the
transfer of web pages to your browser
and browser requests for pages to
servers, is state-less, which means
that once the server has sent a page
to a browser requesting it, it doesn't
remember a thing about it. So if you
come to the same web page a second,
third, hundredth or millionth time,
the server once again considers it the
very first time you ever came there.
This can be annoying in a number of
ways. The server cannot remember if
you identified yourself when you want
to access protected pages, it cannot
remember your user preferences, it
cannot remember anything. As soon as
personalization was invented, this
became a major problem.
Cookies were invented to solve this
problem. There are other ways to solve
it, but cookies are easy to maintain
and very versatile.
See: http://www.quirksmode.org/js/cookies.html
You can pass the value in the query string.
When the user navigate to the other page append the value to the query string and load it in the next.
Another option is jStorage. jStorage is probably better used for cached data and lossy user preferences (e.g. saved username in a login form), as it doesn't have full browser support (but IE6+ and most other common browsers support it) and cannot be relied upon (like cookies).
You can use YUI's Cookie Library http://developer.yahoo.com/yui/cookie/
If JavaScript is disabled what's a way of linking to the previous document in the session history?
Can PHP be used to simply link to the REFERRER or is there a better alternative?
Edit: Further to this, can previous post variables be retained?
You're really mixing the idea of previous document in client session history vs. server session history.
Since Javascript is client-side, executing a history.back() renders the control to the browser, which then decides which page was last in the history (keeping in mind that the last page may not be a page within your domain). When you're using server-side PHP, the HTTP header referrer is whatever the browser supplied to you. If your server-side URI wasn't called as a result of an explicit click on a link, form GET/POST, etc. , your script probably won't get a referrer header value.
If you only want to capture the referrer within your site's domain, you can start maintaining a breadcrumb trail server-side (in the user's session). eg: $_SESSION['breadcrumbs'] = array( 'page1', 'page2', ... )
POST variables can be persisted in the SESSION too though I've never seen a good reason to do so. If you're trying to return an error message for a form and expect to get back the POST, you shouldn't be saving the state of the original POST.