Re: Parsing headers, was: Abstract from HTTP <was> Re: Welcome to JSR 311

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 10 Apr 2007 11:19:59 +0200

Julian Reschke wrote:
>> We have tried to keep the language similar to that of HTTP so it will
>> be familiar to developers who are familiar with HTTP or can easily
>> relate to HTTP through the Java documentation (which IDEs can be
>> present), or are debugging and looking at HTTP messages e.g. using
>> Firebug with Firefox.
>> Similar things could apply for supporting WebDAV.
>> ...
> ...which reminds me that I think we should have the goal to make parsing
> HTTP headers as painless as possible. This includes:
> - decomposing list-style headers, and

Can you enumerate a bit further on the above?

> - parsing according to RFC2047 (, as
> required for the "Slug" header.

Good catch. We could specify a parsing rule, e.g.:

   @HeaderParam(value="slug", type="RFC2047") String slug

(from an aesthetic perspective i really do not like annotations with
more than one parameter, but that is another issue).

Header parameters can also be of any type as long as there is a
constructor that has a String parameter or there is a static String
valueOf() method. So it is possible to do this:

   @HeaderParam("Slug") Slug

Where Slug is say:

   class Slug {
     Slug(String value) { ... }

and it is responsible for parsing according to RFC2047.


| ? + ? = To question
    Paul Sandoz