Conditional request processing with the ETag HTTP response header

Sometimes, you may find that the precision of the HTTP date object (precision in seconds) is not granular enough to decide the freshness of the cache. You can use Entity tags (ETag) present in the HTTP response header field for such scenarios. ETag is part of HTTP/1.1 and provides a way of incorporating caching into HTTP. This tag can be used for comparing the validity of a cached object on the client side with the original object on the server.

When a server returns a response to a client, it attaches an opaque identifier in the ETag HTTP header present in the response. This identifier represents the state of the resource entity returned in response to the client's request. If the resource identified by the URI changes over time, a new identifier is assigned to ETag. When the client makes a request for a resource, it attaches the last received ETag header for the same resource (if any) as the value for the If-None-Match or If-Match HTTP header field in the request. The server uses this identifier for validating the cached representation of the resource. If the state of the requested resource has not been changed, the server responds with a 304 Not Modified status code, which instructs the client to use a copy of the resource from its local cache.

At the bottom level, ETag is different from the Client-Cache and Expires HTTP headers discussed in the previous sections. The ETag header does not have any information that the client can use to determine whether or not to make a request for a specific resource again in the future. However, when the server reads the ETag header from the client request, it can determine whether to send the resource (HTTP status code: 200 OK) or tell the client to just use the local copy (STTP status code: 304 Not Modified). You can treat ETag as a checksum for a resource that semantically changes when the content changes.

To learn more about ETag, visit the following page: http://tools.ietf.org/html/rfc7232#section-2.3.

The following code snippet shows the use of the JAX-RS APIs for building and validating ETag on the server. In this example, the client uses the If-None-Match header field to attach ETag to the request:

@GET 
@Path("departments/{id}") 
@Produces(MediaType.APPLICATION_JSON) 
public Response findDepartmentWithCacheValidationWithEtag( 
    @PathParam("id") Short deptId, @Context Request request) { 
 
        //Reads latest department object from server 
        Department department = findDepartmentEntity(deptId); 
        //Builds ETag for department resource 
        EntityTag etag = new  
            EntityTag(Integer.toString(department.hashCode())); 
 
        //Checks whether client-cached resource has changed  
        //by checking ETag value present in request with value 
        //generated on server 
        //If changed, sends new resource with new ETag 
        ResponseBuilder builder = 
request.evaluatePreconditions(etag); if (builder == null) { builder = Response.ok(department); builder.tag(etag); } } return builder.build(); }

Here is the sample response header generated by the preceding method for the GET departments/10 HTTP/1.1 request:

Server: GlassFish Server Open Source Edition 4.1  
ETag: "03cb35ca667706c68c0aad4cb04c7a211" 
Content-Type: application/json  
Date: Mon, 02 Mar 2015 05:30:11 GMT  
Content-Length: 82 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.166.31