I have added a ParameterizedHeader class. Note that this
implementation ignores any white space between tokens and separators.
That may not always be desirable. HttpHeaderReader does not report
white space, but can ignore and and detect for reporting errors. For
the cases already supported reporting of white space was not required.
My opinion is if you really want to deal with headers specifically
then having a specific class do it (leveraging HttpHeaderReader) is a
better option.
Paul.
On Nov 8, 2008, at 10:03 AM, Paul Sandoz wrote:
>
> On Nov 7, 2008, at 8:34 PM, Craig McClanahan wrote:
>
>> 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.
>>
>
> How about i add such a general class utilizing HttpHeaderReader ?
>
>
>> 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.
>
> It will not work if there are commas in quoted strings of parameter
> values. To do this correctly it is necessary process the string
> linearly as a series of tokens then one can adapt the stream, using
> HttpHeaderListAdapter as follows:
>
> public static <T> List<T> readList(ListElementCreator<T> c,
> String header) throws ParseException {
> List<T> l = new ArrayList<T>();
> HttpHeaderReader reader = new HttpHeaderReaderImpl(header);
> HttpHeaderListAdapter adapter = new
> HttpHeaderListAdapter(reader);
> while(reader.hasNext()) {
> l.add(c.create(adapter));
> adapter.reset();
> if (reader.hasNext())
> reader.next();
> }
>
> return l;
> }
>
> which works for any comma separated header value, be it general or
> more specific.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>