Http conditional get method

Question

When I use java.net.HttpURLConncetion to do conditional GET,
that is, I did connection.setIfModifiedSince(current_time),
but the response codes are always 200, instead of 304.
What shall I do to make such conditional http request work in
Java? Please help! Thanks a lot!!

Answer 1

This sample code works just fine:
import java.net.*;
public class test3 {
  static String testUrl = "http://us.i1.yimg.com/us.yimg.com/i/ww/m6v3.gif";
  public static void main(String[] argv) {
    HttpURLConnection h = null;
    try {
      URL u = new URL(testUrl);
      h = (HttpURLConnection) u.openConnection();
      h.setIfModifiedSince(System.currentTimeMillis());
      h.connect();
      String r = null;
      int i = 0;
      do {
        r = h.getHeaderField(i);
        System.out.println(h.getHeaderFieldKey(i) + " = " + r);
        i++;
      } while (r != null);
    } catch (Exception e) {
      e.printStackTrace();
    } finally {
      if (h != null)
        h.disconnect();
}It outputs this:
null = HTTP/1.0 304 Not Modified
Content-Type = image/gif
Last-Modified = Fri, 15 Apr 1994 00:00:00 GMT
Date = Wed, 27 Nov 2002 11:27:35 GMT
Connection = keep-alive
Expires = Thu, 15 Apr 2010 20:00:00 GMTHowever, you may want to consider this quote from the HTTP 1.1 spec:
Note: When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header field whenever possible.
Note: If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for the same request, the client should be aware of the fact that this date is interpreted in the server�s understanding of time. The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the client and server. This includes the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived from the client�s clock without correction to the server�s clock. Corrections for different time bases between client and server are at best approximate due to network
latency.
So given that my test works fine, I'd argue the problem is not with java, rather it's with your code or the server you're connecting to.
Maybe the server expects the date to be exactly the last modified time of the resource you're accessing, as described in the above note. (Which implies that the current time simply won't trigger 304 status for some servers.) Or maybe the server doesn't believe that the resource is immuatable over some periods of time. (I believe that servers can be configured, for example, always to invoke CGI scripts (and send them with a 200 status, assuming nothing has gone wrong), basically ignoring the If-Modified-Since header.) Note that I was explicitly asking for a GIF in the test code. In my experience with web servers logs, you only see 304's for resources like that.