[
https://issues.apache.org/jira/browse/CXF-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790209#comment-13790209
]
Sergey Beryozkin edited comment on CXF-5244 at 10/9/13 10:18 AM:
-----------------------------------------------------------------
Hi, the problem is that PreMatching ContainerRequestFilter operates on
modifiable Map of headers, so if a given filter happens to set "Content-Type"
on such a map, then the only way to ensure this value is picked up is to check
the map first.
As it happens CXF Message has Message.PROTOCOL_HEADERS and also a pair of
Message.CONTENT_TYPE & Message.ACCEPT_CONTENT_TYPE properties, the latter is
just there to make it simpler to access the most important headers.
If you re-set only Message.CONTENT_TYPE but not sync it with
Message.PROTOCOL_HEADERS then it is not obvious what to do now that
ContainerRequestFilters have to be supported, what if the earlier interceptor
does only update Message.PROTOCOL_HEADERS but not Message.CONTENT_TYPE ?
What I mean is that JAXRSInInterceptor can try and sync
Message.CONTENT_TYPE/ACCEPT_CONTENT_TYPE & Message.PROTOCOL_HEADERS itself to
make sure ClientRequestFilter sees the correct values, but it can not guarantee
it will do the sync direction correctly.
If you do the header updates before JAXRSInInterceptor is used, and not using
JAX-RS 2.0 filters, then please also update Message.PROTOCOL_HEADERS, a bit
more work, yes, but it will be the correct way to do it.
Do you agree ?
thanks
was (Author: sergey_beryozkin):
Hi, the problem is that PreMatching ContainerRequestFilter operates on
modifiable Map of headers, so if a given filter happens to set "Content-Type"
on such a map, then the only way to ensure this value is picked up is to check
the map first.
As it happens CXF Message has Message.PROTOCOL_HEADERS and also a pair of
Message.CONTENT_TYPE & Message.ACCEPT_CONTENT_TYPE properties, the latter is
just there to make it simpler to access the most important headers.
If you re-set only Message.CONTENT_TYPE but not sync it with
Message.PROTOCOL_HEADERS then it is not obvious what to do now that
ContainerRequestFilters have to be supported, what if the earlier interceptor
does only update Message.PROTOCOL_HEADERS but not Message.CONTENT_TYPE ?
What I mean is that JAXRSInInterceptor can try and sync
Message.CONTENT_TYPE/ACCEPT_CONTENT_TYPE & Message.PROTOCOL_HEADERS itself to
make sure ClientRequestFilter sees the correct values, but it can not guarantee
it will do the sync direction correctly.
If you do the header updates before JAXRSInInterceptor is used, and not using
JAX-RS 2.0 filters, then please Message.PROTOCOL_HEADERS, a bit more work,
yes, but it will be the correct way to do it.
Do you agree ?
thanks
> It is not possible to update Content-Type inside JAX-RS 2.0
> ContainerRequestFilter
> -----------------------------------------------------------------------------------
>
> Key: CXF-5244
> URL: https://issues.apache.org/jira/browse/CXF-5244
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.7.6
> Reporter: Dmitry Treskunov
> Assignee: Sergey Beryozkin
> Fix For: 2.7.7, 3.0.0
>
>
> As I understand, it wasn't possible to update headers inside JAX-RS 2.0
> ContainerRequestFilter.
> Is was fixed in this issue https://issues.apache.org/jira/browse/CXF-4986.
> But now update of Content-Type header inside of @PreMatching filter doesn't
> affect further processing -
> suitable MessageBodyReader is selected using initial Content-Type but not new
> one.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
