Hi James,
Just speculating here... what if you add this code to your Application
subclass:
@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 <ja...@carmanconsulting.com>
wrote:
> No thoughts on this one? I'd like to keep my implementation very "vanilla"
> with 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
> unnecessary CXF-specific work-arounds in my code. If we were to "fix" it,
> though, it might introduce a change in behavior and that's not good
> either.
>
> On Fri, Aug 31, 2018 at 8:49 AM James Carman <ja...@carmanconsulting.com>
> wrote:
>
> > I think I misspoke here. Even if I set the header split property, the
> > ContainerRequestContext.getHeaders() still returns concatenated values,
> but
> > if I use a @Context annotation to inject HttpHeaders, I can get back the
> > header values individually (not concatenated). If I take away the header
> > split property, then HttpHeaders starts returning concatenated headers.
> I
> > probably 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 <ja...@carmanconsulting.com
> >
> > wrote:
> >
> >> I found a thread about this topic from 2015, but it seems to be talking
> >> about client-side:
> >>
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/cxf-users/201504.mbox/%3c552bed6b.3000...@gmail.com%3E
> >>
> >> I'm writing a CorsFilter and I need to get the list of
> >> Access-Control-Request-Headers to evaluate them. If I do this:
> >>
> >> JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> >> factory.getProperties(true).put("org.apache.cxf.http.header.split",
> true);
> >>
> >> then everything works fine. However, it seems odd (even after reading
> >> the referred javadocs) that the expected behavior would be concatenated
> >> values. The return type is MultivaluedMap<String,String>. If the
> intent
> >> was that there would always be only one "value" in the map for each key,
> >> then why would they say to return a MultivaluedMap<String,String>?
> Perhaps
> >> this is a problem with the spec or something, but I can't really see in
> the
> >> spec where it specifically says to return the values this way. It does
> >> have a @see pointing to the getHeaderString(String), where it does say
> >> they'd be concatenated. I'm sure I'm missing something here. Thoughts?
> >>
> >> Thanks,
> >>
> >> James
> >>
> >>
>
