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) ?
Paul.