So it sounds like there are two issues here: 1) The "org.apache.cxf.http.header.split" property is applied inconsistently - it works correctly in HttpHeaders, but not in ContainerRequestContext.getHeaders(). This seems like a bug to me. 2) The value for this property should be true by default - this doesn't seem clear in the spec, but I tend to agree with you that it ought to be split by default. Unless somebody says otherwise, I don't think we should change the default behavior in the released streams (3.1.X and 3.2.X). But I think it would be fine to change the default behavior in the 3.3.X (master) stream.
Would you open up a JIRA for these issues? We can probably use one JIRA for both and just mention that the default behavior will remain the same in the service releases. Thanks, Andy On Wed, Sep 12, 2018 at 5:51 PM James Carman <[email protected]> wrote: > Well, it still doesn't even work consistently . Even with that property > set, ContainerRequestContext.getHeaders() returns concatenated values. > HttpHeaders (injected via @Context) does not. > > 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 <[email protected] > > > wrote: > > > 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 <[email protected]> > > 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 < > [email protected] > > > > > > 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 < > > [email protected] > > > > > > > > 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/%[email protected]%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 > > > >> > > > >> > > > > > >
