Musings of an Average Programmer

Now, my French is fairly poor (something I’d really like to remedy) but it seems to me that the Firefox caching issue’s I’ve written about previously have been spotted in France:

http://standblog.org/blog/post/2008/11/20/Firefox-3-et-les-elections-prud-homales

La version 3.0 de Firefox ne vous permettra pas de voter par internet entre le 19 et le 26 novembre. En effet, cette version de Firefox ne garantit pas, pour les élections prud’homales, la confidentialité des informations qui doit être assurée sur un site internet sécurisé.

That seems to me to say something along the lines of a problem in Firefox 3.0 causing it to be barred from some French online elections for reasons of security and privacy.

The good news is it looks like this bug will be fixed for 3.1, and possibly for a future 3.0.x release.

The HTTP/1.1 specification (RFC2616) allows for certain headers to be set to control the caching behaviour of all parties along the request/response chain. That is, all servers, proxy servers, browsers and anything else that sees an HTTP request or response between its source and its destination.

Section 14.9 of the specification defines the behaviour mandated for the "cache-control" header. In common use are the directives "no-cache" and "no-store".

Section 14.9.1:

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.

Section 14.9.2:

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation.

It would seem that the interpretation of these parts of the specification has changed for Firefox 3.

Over at the mozillaZine forums there is a good discussion about this change in behaviour with one user creating some helpful test pages. It seems that setting "Cache-control: no-cache, no-store" no longer prevents Firefox from re-displaying POSTed pages to the user without revisiting the server.

Consider the scenario where a user navigates a series of pages (over an insecure connection) marked with the "Cache-control: no-cache, no-store" header and the clicks the browsers back button. Using Internet Explorer (6 or 7) the user is presented with a "Web Page Expired" warning page, a refresh of which warns the user before resubmitting whatever query data was used to generate the page. The behaviour in Firefox 2 is similar, the user is warned before the relevant query data is resubmitted to the server (the is no warning page in Firefox 2).

With Firefox 3 the earlier page is simply redisplayed to the user without any new server request. It seems that in spite of any "cache-control" setting Firefox 3 will cache any page to it's memory cache device, this fits with the behaviour described in the developer centre FAQ, which states:

Yup, we even store "no-cache" documents in our cache for the reasons enumerated above.

The "reasons above" being history browsing, saving, source viewing etc.

Some digging about seems to reveal that this behaviour change in Firefox 3 is not a bug but is, it seems, a feature (by design) of the new browser. The published minutes for the Firefox 3 status meeting dated 31st January 2007 lists:

P3 - Handling of back/forward with POST

• P3 FR - Cache data from source of POST request
• P3 FR - Return to cached data when going back/forward across POST requests
• P3 NFR - Get rid of the "Do you want to resend the request?" dialog

Implying that the new behaviour is deliberate and expected by the Firefox team. This seems to be a slight deviation from the requirements document which reads:

GKO-002a - Change "Do you want to resend the request?" dialog to an error page

This requirement is distinctly lacking in detail but appears to be requesting that the Firefox behaviour be changed to match that seen in Internet Explorer, this view is backed-up by notes in the status meeting minutes which describe the change as "an IE7 error-page parity issue" and the current behaviour as a bug. It's unclear whether this interpretation is correct, other Mozilla documents imply that "GKO-002a" wasn't implemented but the behaviour has clearly changed.

It's my best guess that the Firefox team have classed the contents of pages accessed via the back button as a "history buffer" and therefore are caching "no-cache" pages for later display to the user. The specification allows for this so technically it seems to be a legitimate decision. The consequences of this however are that potentially sensitive data can be stored in the users "history buffer" and accessed (via the back button, history list etc.) after a logout. Arguably this shouldn't ever be a real problem as if the data is truly sensitive it should be accessed over a secure connection where pages should never be cached. Except my tests show the same behaviour for both secure- and insecure-connections.

It would seem the only current solution to this problem would be to ensure that the browser window is closed once a user has finished.

Update (24/07/2008):  A bug report for this issue can be found here https://bugzilla.mozilla.org/show_bug.cgi?id=441751

Wow. I thought I wanted to do something simple. Turns out adding a JAX-RPC handler to the Axis client-config.wsdd file is harder than you might think. Well, it’s actually not hard, it’s just not documented properly anywhere!

First off the best reference for wsdd is not the Apache Axis site, that’s rubbish, OIO GmbH have a much better version. Far more helpful and far more comprehensive.

Once you’ve got that you’re part-way there.

First, don’t confuse a JAX-RPC handler with an Axis handler, they’re apparently not the same thing. Axis wsdd allows you to configure ‘handler’ and ‘handlerInfo’, the former is an Axis handler, the latter a JAX-RPC handler. If you try to set up a JAX-RPC handler using ‘handler’ you’ll get a class cast exception.

‘handlerInfo’ can only exist inside ‘handlerInfoChain’ which in turn must be inside a ’service’ configuration, like this:

<service name="MyService" provider="java:RPC" style="document"> 
<parameter name=”className” value=”com.foo.services.ServiceImpl” /> 
<handlerinfochain> 
<handlerinfo classname=”com.foo.handler.MyJAXRPCHandler”> 
<parameter name=”parm1″ value=”someValue” /> 
</handlerinfo> 
</handlerinfochain> 
</service>

Your ‘handlerInfoChain’ can’t be inside a ‘requestFlow’ or ‘responseFlow’. JAX-RPC handlers are invoked in both directions of the call anyway, so this would be pointless. You’ll notice from the documentation that the parameter element is optional, except it’s not. Without it your service will work, you’ll get no error or exception, or even a warning, Axis will just silently fail to call your handler.

The ‘className’ parameter is vital. Without this Axis will silently fail when you call your service, not in a way that’ll break the call, but it will stop your handler running. The class name required is that of your service implementation. In the case of the client classes that Axis generates this will be your stub implementation.

Armed with this everything should be straight-forward. Good luck!