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

[jsr339-experts] Re: Modifying headers from ReaderInterceptor

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 20 Sep 2012 11:17:55 +0100

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

Cheers, Sergey

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