Why It Is Necessary To Get Your Website Scanned For Security
Consider this; in one of the largest web based data theft cases, 45 million credit cards were affected. In another case over 40,000 USD mysteriously disappeared from two bank accounts, thanks to a hacker group. In yet another case, when clients of ABC Company and other prospective customers tried to login to company’s website, they were redirected to a competitors page, and the company loses the customer! Apart from direct losses, there are many other indirect losses. According to a whitehat security report in 2008, 9 out of 10 websites are vulnerable or already infected by one or more security threats.
It has become increasingly important to make your website secure, and the first step towards making it secure is to get a thorough website security scan.
Below are the characteristics of a good website scan tool:
• Should be designed to understand the business/website model.
• Should be able to evaluate website security risks.
• Should be updated regularly.
• Should have easy to use website scan dashboard.
• Should provide detailed technical information.
• Should provide easy to understand reports.
• Should provide detailed risk analysis.
• Should provide feasible technical solutions.
There are many benefits that you can reap using these security tools:
• Keep data secure from any infections.
• Increase website availability.
• Gain visitor trust by providing a safe and secure environment.
• Proactive approach against security threats.
• A security assurance seal from a reputed website security provider helps you enhance brand reputation.
• Websites that are more secure gain higher rankings in search engines.
The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine
Today I got this error "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine" when running my ASP.NET web based application on my new laptop with Windows 7 64 bit. It was a form that allows user to upload excel file, then I read the data from excel file into data table object. It used to work in my old laptop, but not in my new one 
.
I have googled around for this issue, have found solution for it. So I took a note here for people who might face same problem as me.
Steps to fix this problem
- Open the IIS Manager
- Click on Application Pools
- Select your web application pool
- Click on the link "Set Application Pool Defaults" on the right hand side
- In General area, turn on "enable 32-bit applications"
Microsoft Jet OLEDB provider is not registered
Web.config/Machine.config Optimal Settings For ASP.NET website
These are what we have collected from different sources as our experiences during our life as ASP.NET web developer 
. More update will come...stay in touch with us...
For production websites, it’s important to remember to set the <Compilation debug =”false” /> setting in Web.config. This ensures no unnecessary debug code is generated for release version of website. If you are not using some of the ASP.NET modules such as Windows Authentication or Passport Authentication etc. then these can be removed from the ASP.NET processing pipeline as they will be unnecessarily loaded otherwise. Below is an example of some modules that could be removed from the pipeline:
<httpModules>
<remove name="WindowsAuthentication"/>
<remove name="PassportAuthentication"/>
<remove name="AnonymousIdentification"/>
<remove name="UrlAuthorization"/>
<remove name="FileAuthorization"/>
<remove name="OutputCache"/>
</httpModules>
ASP.NET Process Model configuration defines some process level properties like how many number of threads ASP.NET uses, how long it blocks a thread before timing out, how many requests to keep waiting for IO works to complete and so on. With fast servers with a lot of RAM, the process model configuration can be tweaked to make ASP.NET process consume more system resources and provide better scalability from each server. The below settings can help performance (a cut down version from an excellent article here):
<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="00:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
responseDeadlockInterval="00:03:00"
responseRestartDeadlockInterval="00:03:00"
maxWorkerThreads="100"
maxIoThreads="100"
minWorkerThreads="40"
minIoThreads="30"
asyncOption="20"
maxAppDomains="2000"
/>
Collected from: Code Project
Minimize Calls to DataBinder.Eval (Collected from MSDN)
The DataBinder.Eval method uses reflection to evaluate the arguments that are passed in and to return the results. If you have a table that has 100 rows and 10 columns, you callDataBinder.Eval 1,000 times if you use DataBinder.Eval on each column. Your choice to use DataBinder.Eval is multiplied 1,000 times in this scenario. Limiting the use ofDataBinder.Eval during data binding operations significantly improves page performance. Consider the following ItemTemplate element within a Repeater control usingDataBinder.Eval.
<ItemTemplate>
<tr>
<td><%# DataBinder.Eval(Container.DataItem,"field1") %></td>
<td><%# DataBinder.Eval(Container.DataItem,"field2") %></td>
</tr>
</ItemTemplate>
There are alternatives to using DataBinder.Eval in this scenario. The alternatives include the following:
Use explicit casting. Using explicit casting offers better performance by avoiding the cost of reflection. Cast the Container.DataItem as a DataRowView.
<%# ((DataRowView)Container.DataItem)["field1"] %>
You can gain even better performance with explicit casting if you use a DataReader to bind your control and use the specialized methods to retrieve your data. Cast theContainer.DataItem as a DbDataRecord.
<ItemTemplate>
<tr>
<td><%# ((DbDataRecord)Container.DataItem).GetString(0) %></td>
<td><%# ((DbDataRecord)Container.DataItem).GetInt(1) %></td>
</tr>
</ItemTemplate>
The explicit casting depends on the type of data source you are binding to; the preceding code illustrates an example.
Use the ItemDataBound event. If the record that is being data bound contains many fields, it may be more efficient to use the ItemDataBound event. By using this event, you only perform the type conversion once. The following sample uses a DataSet object.
protected void Repeater_ItemDataBound(Object sender, RepeaterItemEventArgs e)
{
DataRowView drv = (DataRowView)e.Item.DataItem;
Response.Write(string.Format("<td>{0}</td>",drv["field1"]));
Response.Write(string.Format("<td>{0}</td>",drv["field2"]));
Response.Write(string.Format("<td>{0}</td>",drv["field3"]));
Response.Write(string.Format("<td>{0}</td>",drv["field4"]));
}
Ajax: A New Approach to Web Applications
If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.
Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.
That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.
Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.
Defining Ajax
Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
- standards-based presentation using XHTML and CSS;
- dynamic display and interaction using the Document Object Model;
- data interchange and manipulation using XML and XSLT;
- and JavaScript binding everything together.
The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?
How Ajax is Different
An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.
Who’s Using Ajax
Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.
These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.
At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.
Moving Forward
The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.
It’s going to be fun.
Ajax Q&A
March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.
Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?
A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.
Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?
A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Q. Why did you feel the need to give this a name?
A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.
Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?
A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.
Q. Is Ajax a technology platform or is it an architectural style?
A. It’s both. Ajax is a set of technologies being used together in a particular way.
Q. What kinds of applications is Ajax best suited for?
A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.
Q. Does this mean Adaptive Path is anti-Flash?
A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).
Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?
A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.
Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?
A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.
Q. Are Ajax applications easier to develop than traditional web applications?
A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.
Q. Do Ajax applications always deliver a better experience than traditional web applications?
A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.
To get essays like this one delivered directly to your inbox, subscribe to our email newsletter.
Jesse James Garrett is the Director of User Experience Strategy and a founder of Adaptive Path. He is the author of the widely-referenced book The Elements of User Experience.
Other essays by Jesse James Garrett include The Nine Pillars of Successful Web Teams and Six Design Lessons From the Apple Store.
(Collected from Adaptive Path)
The Benefits of Outsourcing Difficult Web Development Projects
he website development world has tremendously expanded over the past five years, and it doesn´t seem to be shrinking. If you´ve been in the web development field any length of time, you probably realize how much this field has grown and changed.
Simple HTML for many website developers is a thing of the past. Who would have thought that so many programming languages would be invented in such a short period? From simple HTML to PHP, XHTML, CSS, JAVA, FLASH, etc., etc., the list goes on and on!
Outsourcing, although not new to the business world, has quickly become a familiar term in the web development field for this very reason.
Your Niche Web Design Skills
Each website designer has an area of expertise that they´re very familiar with and have performed often. If you took website development in college, you probably focused on just a couple of aspects of development. No one college class teaches all the methods. Perhaps you are very savvy with flash and have created many websites using flash. Of course, there are plenty of potential web design customers in the Flash department, but what if you could expand to other areas of design that you know little about?
Expanding without Additional Training
Perhaps you´ve had the terrible experience of turning clients away simply because you didn´t have the skills necessary to complete their web project. If you´ve had to do this, don´t be too hard on yourself. Nobody has every skill in website development, but everyone in website development has at least one or a few skills!
You might ask, “How can I expand my business or extend services in areas where I´m not an expert?” As mentioned above, outsourcing has become a familiar term in the web development world for this very purpose. Outsourcing gives you an opportunity to expand your business without going to school for more training.
How Outsourcing Works
Outsourcing simply means that you are hiring a person who´s not a direct employee (and often lives out of the country) to complete a web design project for you. Instead of simply referring your client to a new company or individual, you´re actually becoming the middle man between your client and the skilled designer. You still make a profit, the person hired gets paid for their work, the client gets a completed project – and
you get to keep your client!
Even though you´re not skilled in an area of design, you can outsource the work to someone who is skilled in that area.
Outsourcing Your Difficult Projects
Every web developer understands that clients can be easily swayed when working on a project. Your client may hire you to begin designing in simple HTML, which is your area of expertise, but suddenly at midstream, the client has been convinced by an outside influence that PHP is the “way to go” with their website.
If this happens (and it does happen), you have three choices:
1. Tell the client that you´re going to have to continue in HTML, or you won´t be able to complete the project. You lose both the client and the remainder of your pay.
2. Try to convince the client that PHP is NOT the way to go – good luck!
3. Confidently discuss with your client the time frame, any additional costs, and what types of changes will need to be made to redesign the site in PHP. Once you reach an agreement on a PHP direction, you can outsource the work.
Obviously option number three would be best for you and the client. The client won´t have to start over with a new website developer. You´re already familiar with the client´s website needs, goals and business.
You´ll benefit because you get to keep your client and build a good reputation of being a problem solver. You don´t have to tell your client all the details of your outsourcing plans. You can, however, explain that you have a helper who is experienced in PHP, so the client will understand that you´re not working alone on his/her project.
Outsourcing Your Overflow
Another way to use outsourcing to your advantage is when you are so busy that you must turn clients away. If you´re turning clients away, it might be better to keep the clients and outsource the projects instead. You may feel that you don´t need the extra business, however, remember that there are always slow times in any business. The more faithful clients you have, the better! Also, you may offer additional services which can build a monthly income such as web hosting, site updates, etc.
.NET Framework 3.5
.NET Framework (NetFx or Fx) version 3.5 has two elements to it that must be understood: the green bits and the red bits. The original references to this term are on old blog posts by Soma and Jason. Compared to those two blog entries I have the advantage of 13 months of hindsight , so I will provide here the details behind those descriptions in my own words starting with my own slide:
.NET Framework 3.5
When we say red bits, those are Framework bits that exist in RTM today i.e. NetFx v2.0 and NetFx v3.0.
NetFx v3.5 includes updates for those two existing frameworks. However, those updates are not a whole bunch of new features or changes, but in reality a service pack with predominantly bug fixes and perf improvements. So to revisit the terminology: Fx 3.5 includes v2.0 SP1 and v3.0 SP1. Like with all service packs, there should be nothing in there that could break your application. Having said that, if a bug is fixed in the SP and your code was taking advantage of that bug, then your code will break of course. To be absolutely clear, this is an in-place upgrade to v2 and v3, not a side-by-side story at the framework/clr level. I will not focus anymore on the Service Pack (red bits) improvements in Fx 3.5. If you are interested in that you may wish to read my previous blog posts here, here, here and here.
When we say green bits, we mean brand new assemblies with brand new types in them. These are simply adding to the .NET Framework (not changing or removing) just like Fx 3.0 was simply adding to v2.0 without changing existing assemblies and without changing the CLR engine. It is here where you find the brand new stuff to talk about. In Beta 1, the list of new assemblies (green bits) is:
1. System.Data.Linq.dll – The implementation for LINQ to SQL.
2. System.Xml.Linq.dll – The implementation for LINQ to XML.
3. System.AddIn.dll, System.AddIn.Contract.dll – New AddIn (plug-in) model.
4. System.Net.dll – Peer to Peer APIs.
5. System.DirectoryServices.AccountManagement.dll – Wrapper for Active Directory APIs.
6. System.Management.Instrumentation.dll – WMI 2.0 managed provider (combined with System.Management namespace in System.Core.dll).
7. System.WorkflowServices.dll and System.ServiceModel.Web.dll – WF and WCF enhancements (for more on WF + WCF in v3.5 follow links from here).
8. System.Web.Extensions.dll – The implementation for ASP.NET AJAX (for more web enhancements, follow links from here) plus also the implementation of Client Application Services and the three ASP.NET 3.5 controls.
9. System.Core.dll – In addition to the LINQ to Objects implementation, this assembly includes the following: HashSet, TimeZoneInfo, Pipes, ReaderWriteLockSlim, System.Security.*, System.Diagnostics.Eventing.* and System.Diagnostics.PerformanceData.
Collected from Daniel Moth blog
UTF-8 Encoding
In working on a web-based application that needed to support Netscape Communicator 4.x+ and Microsoft Internet Explorer 5.x+, I discovered that the older versions of these browsers had poor support for UTF8 encoding. I needed to find a way to make form field entries URL-safe and also needed to support multiple languages. The JavaScript escape() function fixes ASCII characters that are not valid for use in URLs, but does not handle unicode characters well. To make matters worse, there were browser incompatibilities: using escape() in IE would generate a new string that looked like %unnnn, where n is a hexadecimal digit. The correct encoding should follow RFC 2279 and be a set of hexadecimal digit pairs like %nn%nn. Netscape 4 would just treat the characters as ASCII, which would result in lost accents and umlauts.
The encodeURIComponent() function introduced in IE5.5, Netscape 6, and Mozilla does exactly what is needed. However, since the function is unavailable in Netscape 4.x and IE5, a different solution is needed. All JavaScript strings are unicode, so I expected that it would be possible to properly encode them. Thankfully, someone saw my plea for help and sent me some helpful example code.
I have faced this problem. When using ajax jquery, even I have set the contentType is "application/json;charset=utf-8" it still not working for accented language (like Vietnamese). After searching, I have realized that we have to use this method encodeURIComponent() to encode unicode characters before submitting to server. So I took note it here with a hope that it is useful for ones who may face same problem as mine.
Collected from http://www.worldtimzone.com/res/encode
Optimize caching – Page Speed
Optimize caching
Most web pages include resources that change infrequently, such as CSS files, image files, JavaScript files, and so on. These resources take time to download over the network, which increases the time it takes to load a web page. HTTP caching allows these resources to be saved, or cached, by a browser or proxy. Once a resource is cached, a browser or proxy can refer to the locally cached copy instead of having to download it again on subsequent visits to the web page. Thus caching is a double win: you reduce round-trip time by eliminating numerous HTTP requests for the required resources, and you substantially reduce the total payload size of the responses. Besides leading to a dramatic reduction in page load time for subsequent user visits, enabling caching can also significantly reduce the bandwidth and hosting costs for your site.
Leverage browser caching
Overview
Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network.
Details
HTTP/S supports local caching of static resources by the browser. Some of the newest browsers (e.g. IE 7, Chrome) use a heuristic to decide how long to cache all resources that don't have explicit caching headers. Other older browsers may require that caching headers be set before they will fetch a resource from the cache; and some may never cache any resources sent over SSL.
To take advantage of the full benefits of caching consistently across all browsers, we recommend that you configure your web server to explicitly set caching headers and apply them to all cacheable static resources, not just a small subset (such as images). Cacheable resources include JS and CSS files, image files, and other binary object files (media files, PDFs, Flash files, etc.). In general, HTML is not static, and shouldn't be considered cacheable.
HTTP/1.1 provides the following caching response headers :
ExpiresandCache-Control: max-age. These specify the “freshness lifetime” of a resource, that is, the time period during which the browser can use the cached resource without checking to see if a new version is available from the web server. They are "strong caching headers" that apply unconditionally; that is, once they're set and the resource is downloaded, the browser will not issue any GET requests for the resource until the expiry date or maximum age is reached.Last-ModifiedandETag. These specify some characteristic about the resource that the browser checks to determine if the files are the same. In theLast-Modifiedheader, this is always a date. In theETagheader, this can be any value that uniquely identifies a resource (file versions or content hashes are typical).Last-Modifiedis a "weak" caching header in that the browser applies a heuristic to determine whether to fetch the item from cache or not. (The heuristics are different among different browsers.) However, these headers allow the browser to efficiently update its cached resources by issuing conditional GET requests when the user explicitly reloads the page. Conditional GETs don't return the full response unless the resource has changed at the server, and thus have lower latency than full GETs.
It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.
Recommendations
- Set caching headers aggressively for all static resources.
- For all cacheable resources, we recommend the following settings:
- Set
Expiresto a minimum of one month, and preferably up to one year, in the future. (We preferExpiresoverCache-Control: max-agebecause it is is more widely supported.) Do not set it to more than one year in the future, as that violates the RFC guidelines.If you know exactly when a resource is going to change, setting a shorter expiration is okay. But if you think it "might change soon" but don't know when, you should set a long expiration and use URL fingerprinting (described below). Setting caching aggressively does not "pollute" browser caches: as far as we know, all browsers clear their caches according to a Least Recently Used algorithm; we are not aware of any browsers that wait until resources expire before purging them. - Set the
Last-Modifieddate to the last time the resource was changed. If theLast-Modifieddate is sufficiently far enough in the past, chances are the browser won't refetch it.
- Set
- Use fingerprinting to dynamically enable caching.
- For resources that change occasionally, you can have the browser cache the resource until it changes on the server, at which point the server tells the browser that a new version is available. You accomplish this by embedding a fingerprint of the resource in its URL (i.e. the file path). When the resource changes, so does its fingerprint, and in turn, so does its URL. As soon as the URL changes, the browser is forced to re-fetch the resource. Fingerprinting allows you to set expiry dates long into the future even for resources that change more frequently than that. Of course, this technique requires that all of the pages that reference the resource know about the fingerprinted URL, which may or may not be feasible, depending on how your pages are coded.
- Set the Vary header correctly for Internet Explorer.
- Internet Explorer does not cache any resources that are served with the
Varyheader and any fields butAccept-EncodingandUser-Agent. To ensure these resources are cached by IE, make sure to strip out any other fields from the Vary header, or remove the Vary header altogether if possible - Avoid URLs that cause cache collisions in Firefox.
- The Firefox disk cache hash functions can generate collisions for URLs that differ only slightly, namely only on 8-character boundaries. When resources hash to the same key, only one of the resources is persisted to disk cache; the remaining resources with the same key have to be re-fetched across browser restarts. Thus, if you are using fingerprinting or are otherwise programmatically generating file URLs, to maximize cache hit rate, avoid the Firefox hash collision issue by ensuring that your application generates URLs that differ on more than 8-character boundaries.
- Use the
Cache control: publicdirective to enable HTTPS caching for Firefox. - Some versions of Firefox require that the
Cache control: publicheader to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.
Example
For the stylesheet used to display the user's calendar after login, Google Calendar embeds a fingerprint in its filename: calendar/static/fingerprint_keydoozercompiled.css, where the fingerprint key is a 128-bit hexadecimal number. At the time of the screen shot below (taken from Page Speed's Show Resources panel), the fingerprint was set to 82b6bc440914c01297b99b4bca641a5d:
he fingerprinting mechanism allows the server to set the Expires header to exactly one year ahead of the request date; the Last-Modified header to the date the file was last modified; and the Cache-Control: max-age header to 3153600. To cause the client to re-download the file in case it changes before its expiry date or maximum age, the fingerprint (and therefore the URL) changes whenever the file's content does.
Additional resources
- For an in-depth explanation of HTTP caching, see the HTTP/1.1 RFC, sections 13.2, 14.21, and 14.9.3.
- For details on enabling caching in Apache, consult the Apache Caching Guide.
Leverage proxy caching
Overview
Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remoter origin server.
Details
In addition to browser caching, HTTP provides for proxy caching, which enables static resources to be cached on public web proxy servers, most notably those used by ISPs. This means that even first-time users to your site can benefit from caching: once a static resource has been requested by one user through the proxy, that resource is available for all other users whose requests go through that same proxy. Since those locations are likely to be in closer network proximity to your users than your servers, proxy caching can result in a significant reduction in network latency. Also, if enabled proxy caching effectively gives you free web site hosting, since responses served from proxy caches don't draw on your servers' bandwidth at all.
You use the Cache-control: public header to indicate that a resource can be cached by public web proxies in addition to the browser that issued the request. With some exceptions (described below), you should configure your web server to set this header to public for cacheable resources.
Recommendations
- Don't include a query string in the URL for static resources.
- Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL even if a
Cache-control: publicheader is present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves. - Don't enable proxy caching for resources that set cookies.
- Setting the header to public effectively shares resources among multiple users, which means that any cookies set for those resources are shared as well. While many proxies won't actually cache any resources with cookie headers set, it's better to avoid the risk altogether. Either set the
Cache-Controlheader toprivateor serve these resources from a cookieless domain. - Be aware of issues with proxy caching of JS and CSS files.
- Some public proxies have bugs that do not detect the presence of the
Content-Encodingresponse header. This can result in compressed versions being delivered to client browsers that cannot properly decompress the files. Since these files should always be gzipped by your server, to ensure that the client can correctly read the files, do either of the following:- Set the the
Cache-Controlheader toprivate. This disables proxy caching altogether for these resources. If your application is multi-homed around the globe and relies less on proxy caches for user locality, this might be an appropriate setting. - Set the
Vary: Accept-Encodingresponse header. This instructs the proxies to cache two versions of the resource: one compressed, and one uncompressed. The correct version of the resource is delivered based on the client request header. This is a good choice for applications that are singly homed and depend on public proxies for user locality.
- Set the the
- Source from: http://code.google.com/speed/page-speed/docs/caching.html