[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807007#comment-17807007
]
Andriy Redko edited comment on CXF-8812 at 1/16/24 2:02 AM:
------------------------------------------------------------
Hey [~enrice] ,
Thanks for reporting this behavior, what looked like a bug turned out to be
quite a designed behavior, there are 2 parts to this:
* the Content-Type header is indeed not sent in the request, and the CXF sets
the header to "null" (since headers are multivalues, it is represented as a
singleton list with "null" value)
* it is logical to assume that if header is not present, it should not be in
the list of headers (or at least have a "null" value), but the Content-Type is
used in many places and large number of critical paths rely on the presence of
the Content-Type header (not its value) for historical reasons, so removing it
breaks the existing applications
At the end, the value of the header is still "null":
{code:java}
String requestHeader = httpHeaders.getRequestHeader("Content-Type").get(0)
{code}
So the fact it is present as a collection with single "null" (even if not sent
in the request) could be a bit confusing / annoying at first, but it should not
lead to any behavior change.
was (Author: reta):
Hey [~enrice] ,
Thanks for reporting this behavior, what looked like a bug turned out to be
quite a designed behavior, there are 2 parts to this:
* the Content-Type header is indeed not send it the request, the CXF sets the
header to "null" (since headers are multivalues, it is represented as a
singleton list with "null" value)
* it is logical to assume that if header is not present, it should not be in
the list of headers (or at least have a "null" value), but the Content-Type is
used in many places and large number of critical paths rely on the presence of
the Content-Type header (not its value) for historical reasons, so removing it
breaks the existing applications
At the end, the value of the header is still "null":
{code:java}
String requestHeader = httpHeaders.getRequestHeader("Content-Type").get(0)
{code}
So the fact it is present as a collection with single "null" (even if not sent
in the request) could be a bit confusing / annoying at first, but it should not
lead to any behavior change.
> Content-Type header created with collection containing "null" value
> -------------------------------------------------------------------
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
> Reporter: Erich Mauerböck
> Assignee: Andriy Redko
> Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
