users@jersey.java.net

Re: [Jersey] Initial crack at HeaderValue class (and corresponding unit test)

From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
Date: Fri, 07 Nov 2008 11:34:44 -0800

Paul Sandoz wrote:
>
> On Nov 7, 2008, at 8:08 PM, Craig McClanahan wrote:
>
>> Paul Sandoz wrote:
>>> Hi Craig,
>>>
>>> I have re-factored the header stuff in jersey-core to be part of the
>>> API and added the following:
>>>
>>> com.sun.jersey.core.header.ContentDisposition
>>> com.sun.jersey.core.header.FormDataContentDisposition
>>>
>>> that can used by jersey-multipart for processing content disposition
>>> headers (currently for reading, need to me modified for writing). I
>>> need to add some tests. Perhaps they make sense as part of multipart
>>> module? I did not create any general header type because i am not
>>> sure if that is appropriate or not. Feel free to modify/move/add as
>>> appropriate.
>>>
>> I saw the commit notices ... will take a look later today.
>>
>> Regarding a general purpose header class, you can tell I'm an
>> architect at heart :-) ... I like to generalize things that look like
>> they might be generally useful. When reviewing the HTTP and other
>> specs while thinking about this, I was a bit surprised how often
>> parameterized headers show up. And the fact that apps can construct
>> their own headers sure makes me think there are use cases for parsing
>> header values far beyond these two.
>
> Good point. What made me pause is one can consider three forms of
> headers with parameters:
>
> 1) a token + parameters (e.g. AcceptLanguages: en;q=1.0)
>
> 2) a list of tokens delineated by separators + parameters
> (e.g. Accept with a single value: application/xml;q=1.0 )
>
> 3) 1 or 2 as a comma separated list.
>
> I created a pull-based reader to make it easier to efficiently parse
> (avoiding the creation of many String instances, indexof/trims etc) in
> all three cases (it handles the cases of quoted strings and
> comments). I guess what you are proposing is to have a general header
> value that combines 1) and 2) ?
Pretty much. You can think of 1) and 2) as being identical if you only
consider comma and semicolon to be delimiters -- the slash in a media
type is just another character.

For 3) I consider that to be multiple header values, so you should get a
list back when you parse it. In my implementation last night, I
included a static method (HeaderValue.parseHeadervalues()) to take care
of this scenario.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>