Content Negotiation Filter

Created: 2012/12/03 21:35:26+0000 Revised: 2013/11/08 23:26:09+0000 Revisions:  11 10 9 8 7 6 5 4 3 2 1

As part of the (limited) linked data I provide on this website I implemented a content negotiation filter to provide the 303 redirects. It is configured with an XML file that describes the possible variants. The content negotiation algorithm is based on the Apache Negotiation Algorithm but lacks support for the encoding and character set.

I implemented this myself because when I was trying to find out how I should do this I kept finding Paul Tuckey's UrlRewriteFilter and JAX-RS which uses annotations. The UrlRewriteFilter only supports string matching on the accept header and 302 redirects. JAX-RS and annotations had nothing to do with how I was implementing my website.

With the content negotiation filter I also make available some basic filter utilities and a way to structure HTTP headers. Both of these are used by the content negotiation filter. The filter utilities are used to reduce the boilerplate code required for the filter. The structured HTTP headers are used to evaluate and compare the content type and language header field values of requests.

I used Maven as the build tool for this. Some of you may have heard me say that I prefer Ant and this is true. One of the problems I have with Maven is that the lifecycles make it unsuitable for persistent data stores, this does not apply here. What I like about Maven is the dependency management, which I usually take advantage of using Ivy. Ivy does support publishing to a repository but I felt that it would be more straight forward to use Maven and there wasn't anything I wanted to do that Maven would make difficult.

It is currently available from source control at BitBucket, It has also been released to the Maven central repository.

Group IDcom.mattunderscore
Artifact IDcontent-negotiation
Dependenciesjavax.servlet.servlet-api, junit.junit, org.hamcrest, com.mattunderscore.filter-utils, com.mattunderscore.structured-http-headers, org.mockito.mockito-all
Show all

It is now in three artifacts, I have successfully converted it to a multi-module project. The Maven generated site is available at I am sure you will all be very glad to learn that this release does contain automated testing and test coverage reports. What next? Improved test coverage? Continuous integration? Enough documentation for you to use it? Turns out minor changes, slightly improved test coverage and better documentation. I'm going to skip the continuous integration since I'm the only person working on this project.

I have been improving the way the filter gets variants. I have deprecated the NegotiationXMLParser class and introduced the VariantSource interface. The variant sources use composition to build up the features of the classes. This allows more generic ways of getting the variants. I currently have an XML parser implemented but I am using a SAX parser instead of a DOM parser.

For those of you interested in linked data for this project, see here: