Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] user guide's chapter-10 MISTAKES

Thank you for your response.
I appreciate your detailed explanation of my concerns.

also, do you accept feedback in the mailing list?

On Tue, Jan 22, 2019 at 7:57 PM Jan Supol <jan.supol@xxxxxxxxxx> wrote:
Hi Rawand,

please see inline.



On 15.01.2019 14:51, rawand takna wrote:
> 1- example 10.5. GZIP writer interceptor
> the "*Content-Encoding: gzip*" header is not set after compressing the
> response entity which leads to the following problem:
> when a user-agent (ex: chrome) receives the compressed response, it
> *does not know* whether the response is compressed or not since that
> is indicated
> with the presence or absence of the Content-Encoding header.
> thus, it *assumes *that the response entity is *NOT *compressed and
> *shows the compressed* response entity directly without unzipping.
Yes, the content encoding header was omitted for the simplicity, as the
Example 10.5 works in the conjunction with Example 10.6, which in turn
decompresses the stream, as it expects the stream to be compressed, no
matter the Content-Encoding header.
> 2- quoting from section 10.3 Interceptors of the user's guide
> "Similar to methods exposed by WriterInterceptorContext the
> ReaderInterceptorContext introduces a set of methods for modification of
> request/response properties like HTTP headers,*URIs and/or HTTP methods*"
> *URIs and/or HTTP method* must not be modified in
> *ReaderInterceptorContext *as the *resource matching process* is done
> *before *the execution of *ReaderInterceptor(s)*
> as mentioned in 10.4. Filter and interceptor execution order
Correct, it was copy-pasted from filters. We should change it.
> 3- Example 10.9. Priorities example
> quoting from the user guide:
> "As this is a response filter and response filters are executed in the
> reverse order, any other filter with a priority lower than
> 3000 (Priorities.HEADER_DECORATOR is 3000) will be executed after this
> filter. So, for example, *AUTHENTICATION *filter (priority 1000)
> would be run after this filter."
> isn't *AUTHENTICATION *filter a *REQUEST *filter?
> how is it possible that an AUTHENTICATION filter is executed along
> with response filters?

The Priorities enum contains (AUTHENTICATION, AUTHORIZATION,
HEADER_DECORATOR,...). The example took any priority value defined by
Priorities enum which is less then Priorities.HEADER_DECORATOR. There
are only two: Priorities.AUTHENTICATION and Priorities.AUTHORIZATION, so
not a much choice.

A filter with @Priority(Priorities.AUTHENTICATION) does not mean it
actually is an authentication filter. It means it has the same priority
as potential authentication filter would have. It can be any filter,
with priority 1000. What is important in the example is to explain that
for request filters the priority is processed in ascending order, for
response in descending, which I believe it does.

And it seems it leads people to think about what is written there, which
is good, too :)

> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
jersey-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top