There are a number of reasons why browser could make a conditional or unconditional request for item that is already in the cache.

Item is expired

The cached data is no longer fresh according to Cache-Control or Expires.

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.

Browser applied its heuristic and decided that item should be revalidated by server based on

Last-Modified and ETag. These specify some characteristic about the resource that the browser checks to determine if the files are the same. In the Last-Modified header, this is always a date. In the ETag header, this can be any value that uniquely identifies a resource (file versions or content hashes are typical).

Last-Modified is 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.More...

Finally found some time to upgrade simple, but very useful rating control for Sencha Touch community.

GitHub (see branch sencha2): https://github.com/podlipensky/Ext.ux.touch.Rating/tree/sencha2

Demo: http://podlipensky.com/sencha2/rating/example/

Sencha Touch team did a great job in this release, but it looks like a lot of changes were made. Control’s architecture and lifecycle was changed drastically. For example, there is no render or afterrender events, but you can use painted event instead (although it occurs each time control became visible).

Anyway, I think they’re on the right way, and for those who haven’t migrated from Sencha Touch 1.x to 2.0, I’d recommend to read the following resources:

http://www.sencha.com/conference/session/migrating-from-touch-1.x-to-2.0

http://www.sencha.com/learn/upgrading-to-sencha-touch-2-pr2/

http://francisshanahan.com/index.php/2011/sencha-touch-2-0-mvc-in-5-minutes-or-less/

http://docs.sencha.com/touch/2-0/#!/video/migrating-from-1-to-2

Ext.ux.touch.Rating 2.0 control and its configuration is different from 1.x version, so please review changelog before migrating. Please note that it doesn’t support items collection in configuration anymore (it will be generated internally in any case). Here is an example of Ext.ux.touch.Rating field configuration:

{ 
       xtype: 'rating', 
       label: 'Star w/ clear',                               
       itemsCount: 5, 
       itemCls: 'x-rating-star', 
       itemHoverCls: 'x-rating-star-hover', 
       clearIcon: true //show clear icon right after stars 
}

or

new Ext.ux.touch.Rating({// alternative way to instantiate class in ST 2.0
       itemsCount: 5, 
       label: 'Image less', 
       cls: 'x-imageless-rating', 
       itemCls: 'x-imageless-star', 
       itemHoverCls: 'x-imageless-hover' 
})

I didn’t migrate experimental versions of rating control, such as Ext.ux.touch.CirlceRating. But added image-less version of the rating control for those who cares about mobile page weight (and performance overall).

Also I added an example of rating-as-action-sheet usage:

Enjoy!

Today I’d like to continue browser’s cache topic and discuss one of the ways user can invalidate cached resources. I’m talking about F5 versus CTRL+F5 shortcuts (versus other ways to “refresh” the page) in modern browsers. So what is the difference between pressing F5 or CTRL+F5 in a browser window?

HTTP Request Types

First, let’s step back for a moment and take a look into HTTP theory.

Web browsers make two types of requests over HTTP(S) - conditional requests and unconditional requests.

An unconditional request is made when the client browser does not have a cached copy of the resource available locally. In this case, the server is expected to return the resource with a HTTP/200 OK response. If the response’s headers allows it, the client may cache this response in order to reuse it later.

If the browser later needs to retrieve the resource which is available locally (in cache). That resource’s header are checked in order to determine whether it is fresh or not. If the cached copy is still fresh then no server request will be made at all.

After that if the browser needs the resource, which is in the cache, but expired already (older than its max-age or past the Expires date), then client will make conditional request in order to figure out whether cached copy could be reused or should be replaced with some fresh version of the resource. The conditional request contains an If-Modified-Since and/or If-None-Match header that indicates to the server what version of the content the browser already has in its cache. If browser’s version is still valid, the server will return HTTP/304 Not Modified headers with no body, otherwise it can return HTTP/200 OK response with the new version of the resource.

More...

As you may know there are several ways to “tell” the browser or proxy-server what to cache and what to do not cache. They’re reliable and commonly used across the browsers, but if there is no proxy-cache in the middle and user disabled browser’s cache then your client cache policy will be ignored. In this case you may want to adjust your cache policy and be more effective in cache-less environment.

Before starting our findings, I’d like to outline that I’ll test my approach in IE8, IE9, FF 9 and Chrome 18 browsers. Also we should assume that there is no proxy-caches or reverse proxy-caches on the way to the server. All results in my experiment will be sent to javascript console.

CSS caching and optimizations

So, let’s consider the ways to check browser (or proxy) cache availability. The main idea is simple – load some mutating resource couple times and see whether they (copies) are equal or not. By saying “mutating resource” I mean .css or .js or any other resource which has different content each time user request it from the server. For example, we may have .css file with the following content:

.cachedetect{ width: [incremental number here]px; }

where [incremental number here] will be replaced with some different number each time the resource is requested. Then we will apply .cachedetect style to some div element on the page and measure it’s width by using javascript. And finally we can say whether div’s width was changed after browser downloaded the .css file for the second time.

But having such .css is a bad approach as browsers (except IE9) have implemented optimization to do not load the same .css file twice if it’s address is equal. In other words, such html will lead to only single HTTP request to the server:

<link type="text/css" rel="stylesheet" href="cssdetect.css">
<link type="text/css" rel="stylesheet" href="cssdetect.css">

Amusingly, if first .css request was done from HTML markup, and second one was done from javascript, then even IE9 won’t download it for second time.

More...

Certainly visiting websites such as your bank account or email via HTTPS is much safer than just by using HTTP. At least it should protect you from Man-in-the-middle-attack. But please remember that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. It’s has been known that accessing first page of the website via HTTP and then continue via HTTPS is not-so-secure-as-you-think.

However, even if you accessed the website via HTTPS from start it doesn’t guarantee you full protection.

Consider:

1) you visit https://secure.example.com/ which drops a cookie on your browser

2) you then visit http://www.google.com/ however a MITM inserts

<div style='visibility:hidden'>
   <iframe src='http://secure.example.com/'></iframe>
<div>

3) MITM sniffs your cookie from the request on the iframe

More...

In my previous post we’ve built basic functionality for image-free volume control. Now it’s time to make it sexy. Just to remind you, here is what our final result should look like:

But now it looks like this

First of all let’s make our knob look like metal one. More...

There is always a place for inspiration in developer’s life. Especially when it comes to web design of real world things such as volume control for your fancy CD player. So I decided to take a challenge and design similar to  Nikolay Samoylov’s sound control by using CSS3, minimum of JavaScript and no images of course.

Our final result will look like this

My target browser will be WebKit only (don’t have time to do cross-browser support), and for more complexity let it be Mobile WebKit.

More...