So, I wrote a simple filter to test this out on Jersey and it also does NOT
split the headers:
@Provider
public class DumpHeadersFilter implements ContainerRequestFilter {
@Context
private HttpHeaders httpHeaders;
@Override
public void filter(ContainerRequestContext requestContext) throws
IOException {
Map<String,Integer> valueCounts = new HashMap<>();
httpHeaders.getRequestHeaders().forEach((name,values)->{
valueCounts.put(name, values == null ? 0 : values.size());
});
requestContext.abortWith(Response.ok(String.valueOf(valueCounts),
MediaType.TEXT_PLAIN_TYPE).build());
}
}
I flipped this between using the injected HttpHeaders and the
ContainerRequestContext and they both return 1's for all the counts.
Apparently there was a JIRA issue (JERSEY-2164) filed for this as a bug.
There's even a test case:
https://github.com/eclipse-ee4j/jersey/blob/master/tests/integration/jersey-2164/src/test/java/org/glassfish/jersey/tests/integration/jersey2164/Jersey2164ITCase.java
This is how I found JERSEY-2164 (the JIRA link is dead):
https://www.logicbig.com/how-to/jax-rs/jax-rs-multi-header-example.html
This is just very odd, though. Why on Earth would the spec return
MultivaluedMap if it didn't intend for there to be multiple values? This
just seems very counter-intuitive.
What do we want to do here? The one PR at least makes it consistent wrt
our "split headers" setting between ContainerRequestFilter.getHeaders() and
HttpHeaders. Should we integrate that only and leave the default behavior
alone?
Thanks for all your time, guys. I really appreciate it.
James
Post by Andy McCrightHi James,
Looks as inconsistency on the first view.
Could you invest a bit more efforts and check how Jersey behaves in this case?
Regards,
Andrei.
-----Original Message-----
Sent: Donnerstag, 13. September 2018 00:51
Subject: Re: ContainerRequestContext.getHeaders() Returns Concatenated
Values?
Well, it still doesn't even work consistently . Even with that property
set,
ContainerRequestContext.getHeaders() returns concatenated values.
What I'm trying to determine is if this really is expected behavior.
I've looked
at the spec and can't really find where it says these should be
concatenated
values. I'm sure I missed something.
I actually don't typically usually use an Application class in my JAX-RS
projects,
at least not with CXF. I get that's the only really portable way to
register stuff,
but I typically don't.
On Wed, Sep 12, 2018 at 6:38 PM Andy McCright
Post by Andy McCrightHi James,
Just speculating here... what if you add this code to your Application
@Override
public Map<String, Object> getProperties() {
Map<String,Object> props = new HashMap<>();
props.put("org.apache.cxf.http.header.split", true);
return props;
}
I think that might a more portable approach that does the same thing...
Hope this helps,
Andy
On Sat, Sep 8, 2018 at 8:00 AM James Carman
Post by James CarmanNo thoughts on this one? I'd like to keep my implementation very
"vanilla"
Post by James Carmanwith respect to the JAX-RS spec, but I am using CXF as my JAX-RS
implementation during testing. I just want to make sure I'm not doing
any
Post by James Carmanunnecessary CXF-specific work-arounds in my code. If we were to
"fix"
Post by Andy McCrightit,
Post by James Carmanthough, it might introduce a change in behavior and that's not good
either.
On Fri, Aug 31, 2018 at 8:49 AM James Carman
Post by James CarmanI think I misspoke here. Even if I set the header split property, the
ContainerRequestContext.getHeaders() still returns concatenated values,
but
the
Post by James CarmanPost by James Carmanheader values individually (not concatenated). If I take away the
header
Post by James CarmanPost by James Carmansplit property, then HttpHeaders starts returning concatenated
headers.
Post by Andy McCrightPost by James CarmanI
Post by James Carmanprobably should have said so in my original email, but I'm using
CXF v3.2.6.
On Fri, Aug 31, 2018 at 8:35 AM James Carman <
Post by James CarmanI found a thread about this topic from 2015, but it seems to be
talking
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.ap
ache.org_mod-5Fmbox_cxf-2Dusers_201504.mbox_-
253C552BED6B.3000809-40gm
253E&d=DwIBaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm
Post by Andy McCright-lcbhtB3cv08OlIr0lkKR4&m=LtVUiAWp616aAPUnohJFxm_7-
hgmuQHkcURHKrhRpBI&s
Post by Andy McCright=aRsXwOJ2jihkyx9DqweSVqU5t3C9TwVls5OwhTdDPZk&e=
Post by James CarmanPost by James CarmanPost by James CarmanI'm writing a CorsFilter and I need to get the list of
JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.getProperties(true).put("org.apache.cxf.http.header.split
",
true);
Post by James CarmanPost by James Carmanthen everything works fine. However, it seems odd (even after
reading the referred javadocs) that the expected behavior would
be
concatenated
Post by James CarmanPost by James CarmanPost by James Carmanvalues. The return type is MultivaluedMap<String,String>. If the
intent
Post by James CarmanPost by James Carmanwas that there would always be only one "value" in the map for each
key,
Post by James CarmanPost by James CarmanPost by James Carmanthen why would they say to return a MultivaluedMap<String,String>?
Perhaps
Post by James CarmanPost by James Carmanthis is a problem with the spec or something, but I can't really see
in
Post by James Carmanthe
Post by James CarmanPost by James Carmanspec where it specifically says to return the values this way.
It
does
Post by James CarmanPost by James CarmanPost by James Carmandoes say they'd be concatenated. I'm sure I'm missing something
here.
As a recipient of an email from Talend, your contact personal data will be
on our systems. Please see our contacts privacy notice at Talend, Inc. <
https://www.talend.com/contacts-privacy-policy/>