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