Internet Explorer 7 is supposed to support gzip and deflate encoding. Right? Despite the support advertised via the Accept-Encoding header, I noticed it does only support gzip encoding, but not deflate.

Prompted by Joe Gregorio's How To Do RESTful Partial Updates, there were a lot of discussions over the weekend about partial updates. James Snell just captured the list of reactions in his latest post, and so there is no need to repeat them here. While Joe Gregorio's post is an interesting attempt at encoding the diff into URIs, I would argue that, contrary to what the title of his post suggests, encoding a diff into a URIs is not a generic solution for partial updates. Please note that, while Joe Gregorio's post just focused on Atom, I am extending this to XML in general in this post.

In the Java-land, it is common to use java.net.URLEncoder to safely encode reserved characters into URIs. However, what java.net.URLEncoder does is to apply application/x-www-form-urlencoded encoding which is different from treating reserved characters in the RFC-3986 way.

I am surprised to find that Google.com has an open redirector service to redirect to arbitrary third-party web sites. If you look at Aviv Raff's report on a new Google Toolbar Dialog Spoofing Vulnerability, at the heart of the vulnerability is an open redirect service hosted on Google servers. This service can be used, independently of the Google Toolbar, to redirect the user to any arbitrary web site. Although Aviv Raff did not demonstrate this point, this redirector can be used to make the user download executable content from other sites. For hackers, the possibilities are end less. Since the URL starts with a google domain, the user is very likely to trust the downloaded content. Here is how this works.

As I was looking at some design issues around some REST APIs, I had a chance to investigate the HTTP/1.1 Vary header. As it turns out, there are interesting implications around setting or not setting this header or setting this header incorrectly. Here is my notes on the rationale behind the Vary header, and design guidelines.

For some experiments on the HTTP/1.1 Vary header, I just setup the Squid web proxy on my Mac. Here are the three quick steps to get Squid up and running as a web proxy on a Mac.

Here is a sequence illustrating how cookies can make GET requests short-lived and useless.

Using a modern browser, through a company's careers page, I went to a job search site, filled in a search form, and searched for some jobs. There was no registration involved, and I was visiting this for the first time. I browsed through the search results, clicked on a few job listings, and emailed links to some of those to someone else. That other person clicked on those links, and got back this page below.

Recently I came across an article at InfoQ that talks about using Using ETags to Reduce Bandwith & Workload with Spring & Hibernate. Unfortunately, the implementation suggested in this article is such that validating the ETag takes as much time (if not more) as generating the resource itself. This is an example of a premature and incorrect optimization. This article barely scratched the surface of the problem with computing caching headers (both expiry related and invalidation related) for dynamic resources.

I was curious to see how good various blog readers are at HTTP content-negotiation, and over the weekend, I tried some experimentation. Content-negotiation in HTTP 1.1 is a very useful feature which lets the web server tailor the response based on certain HTTP request headers. One popular example is to serve localized content based on the Accept-Language header. I set to try out a similar style negotiation based on what kind of content the client is capable of processing - in my case the clients are blog readers, and the results were disappointing.

Will the goal to keep web services protocol agnostic cause web services to implode? May be so, given that protocol abstraction is making web services design and deployment more complex than necessary.

HTTP 1.1 supports six kinds of redirects, and each of these mean different things and has its own applications. Depending on your use cases, a call to HttpServletResponse.sendRedirect() from a web app may or may not work correctly. Here is a rundown of the key differences between the various kinds of redirects and their possible applications.

A lot has been written about caching issues with XMLHttpRequest based apps. There is certainly some amount of frustration and confusion about this topic. I had the same kind of experience when I updated my blog recently to show a paginated blog entry list via an XMLHttpRequest. I noticed that mainstream browsers behave inconsistently when it comes to caching.

In my previous post on HTTP Caching, I left out two topics. The first is caching dynamically generated files (e.g. pdf). The second is choosing headers like Expires, Last-Modified etc.

Over the weekend I was searching a well-known electronics manufacturer's site for an LCD monitor. After finding the product page I was looking for, I bookmarked the page, and then went on to surf something else. After a few minutes, I came back and reloaded the bookmarked page. I expected my browser to load the page immediately from its cache, but it did not. I was curious to find out why. It turned out that the server did not send any cache related HTTP headers, forcing my browser to request for the page again. What a waste of bandwidth and CPU cycles!

The Content-Length header is an interesting HTTP response header. This header tells HTTP client applications the size of the response. However, in HTTP 1.1, this header is optional. HTTP applications need not set this header if the size is not known. This is in fact the case with most applications that generate dynamic content.