Skip to content

Browser Caching

It depends on how your website/web application is used, but browser caching can give you fantastic performance increases for very little effort. Especially with a database driven site that is primarily read-only (many ecommerce sites), proper browser caching can decrease the number of pages you serve per user, which in turn increases the number of users supportable by a given set of hardware.

I found this caching tutorial to be very helpful in understanding just how to cache pages, as well as RFC 2616, which states in section 13.2.4 that the Cache-control: max-age header takes precedence over the Expires header (for the browsers who speak HTTP 1.1). This examination of the support of various browsers is also excellent reading. There’s also a cool tool called the Cacheability Engine which examines caching behavior of web pages, if you don’t want to look at the headers yourself (using Fiddler or LiveHTTPHeaders). I encountered occasional errors with the engine, but it was pretty neat to use.

[tags]browser caching[/tags]

GWT Internet Explorer quirks

I am building another GWT component and ran across two IE quirks that I would like to share.

1. Multiple modules on one page: I could not find a way to have two GWT modules on the same page–that is, having two gwt:module meta tags on one page. (Having two on one page works fine in FireFox, as long as gwt.js is only included once.) Instead, I followed the advice in this post, and created a hybrid module that inherited from both modules I wanted to display. In the two modules I was inheriting from, I simply check to see if a span is available to put the module’s UI in. (Don’t forget that inheritance is defined differently for GWT than for a typical programming language.)

2. Cookie size limits: Cookies set by GWT have limit in size in IE. Again, I didn’t see the same behavior with FF1.5, but IE 6.00.29 has a limit of 802 characters in the value portion of a cookie. (The name I was using was 5 characters long.) Longer values can be set, and are sent to the server, but I could not find a way to read cookies with a length longer than 802. I didn’t drop down into JSNI because I looked at the Cookies source code and couldn’t see what I’d do different.

Update Dec 5 2006: I was trying to nail this down to submit a bug report to Google, but saw some really weird behavior with IE’s cookies. It seemed to handle a cookie longer than 802, then it seemed to not handle such a cookie, and now it is handling a cookie with value length of 1202. See this page for an example. The first two cookies have a length of 802, the second two have a length of 1202. Weird!

[tags]cookies,GWT, Google Web Toolkit, Internet Explorer, multiple modules[/tags]

Uploading a file in php using an iframe

I recently wrote a PHP file upload application. Yawn, right? There’s a manual entry on this task, which tells you just how often folks need to do it.

Well, I threw in a few new tricks–they were new to me at least. Basically, instead of posting to a page in the typical way, I post to a 1px by 1px invisible iframe, which then generates some javacript:

<form action="/upload.php" enctype="multipart/form-data"
method="post" target="target_upload">
<iframe id="target_upload" name="target_upload"
style="border: 0pt none ; width: 1px; height: 1px">

———–

<script type="text/javascript">
if (parent && parent.uploadFinished) {
parent.uploadFinished(<?php echo $result;?>);
} </script>

The next question is how to communicate from the iframe, which is handling the processing, to the parent window, which is where the user interface is. The upload process parses the file and puts it in a database. If there are any errors, the parsing code ouptuts “0”, otherwise, it returns “1”. This value is passed to a javascript function which is written to the iframe. It looks something like the above, where the uploadFinished function basicly shows divs containing an appropriate message.

How is this superior from a regular page post? Not by very much. It’s not truly asynchronous–you still see the browser wheel spin. The only browser actions you can take while an upload is proceeding are those that open in a new window. That’s not much, but it’s more than a normal post allows you to do. In addition, this is relatively easy to do and you don’t have to deal with creating a new ‘successful upload page’.

[tags]PHP, file upload[/tags]