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 (http://tools.ietf.org/html/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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109