jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Modifying headers from ReaderInterceptor

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Thu, 20 Sep 2012 10:15:08 -0400

On Sep 20, 2012, at 6:17 AM, Sergey Beryozkin wrote:

> If MessageBodyReaders had the same capability to modify the input headers, then it would cause some minor issues I'm referring to below.
>
> Reader interceptors are effectively higher-level MBRs. IMHO that is another reason why they should not be able to modify the headers

 Off top of my head I can't think of any UC for which having writable headers in the reader context would be useful.

-- Santiago

> On 19/09/12 21:50, Sergey Beryozkin wrote:
>> Hi,
>>
>> I've done few tests with ReaderInterceptor and I'm getting some doubt
>> about the fact ReaderInterceptorContext offers a modifiable map of
>> headers to individual interceptors.
>>
>> On the server side it becomes awkward to handle the following:
>>
>> @POST
>> public Book echoBook(@HttpHeader("bar") String bar, Book book) {}
>>
>> Note that a ReaderInterceptor chain is run if MBR for Book is available.
>> In this example, Book parameter is second one in the list of in
>> parameters, so some extra work (was not needed in JAX-RS 1.1 nor needed
>> in 2.0 when no explicit HttpHeaders are there) has to be done to
>> accommodate for the fact a custom ReaderInterceptor can update the
>> request headers - not a big issue but complicates things and makes it a
>> tiny bit slower.
>>
>> On the client side:
>>
>> Response r = getResponse(...);
>> String bar = r.getHeaderString("Bar");
>>
>> // reader interceptors run now
>> r.readEntity(Book.class);
>>
>> String bar2 = r.getHeaderString("Bar");
>>
>> // bar2 and bar values may be different
>>
>> I'm not sure if you see it as an issue but I think it makes sense to
>> consider making the headers visible to custom reader interceptors
>> read-only.
>>
>> IMHO it's better be done at the filter level, modifying the headers as
>> needed. I do not see a good reason for also letting reader interceptors
>> which run after the filters also be able to modify the headers. Keeping
>> headers in a read-only will make things simpler without imposing the
>> limitations - in fact a read-only mode can be relaxed without breaking a
>> backward compatibility in the future if really needed
>>
>> So, I propose to make the headers visible to reader interceptors read-only
>>
>> Sergey
>