Andy, I've submitted a PR for the splitting part (not the changing the defaults):
https://github.com/apache/cxf/pull/445 There was some funky stuff going on in there with how it nulls out the existing HttpHeaders object on the ContainerRequestContextImpl. I wasn't quite sure why that was being done and changing it didn't break any tests. Hope this will work. Let me know. On Thu, Sep 13, 2018 at 3:41 PM Andy McCright <j.andrew.mccri...@gmail.com> wrote: > By all means! :) Let me know once you've got something ready for review. > > Thanks! > > On Thu, Sep 13, 2018 at 2:31 PM James Carman <ja...@carmanconsulting.com> > wrote: > > > Yeah, no problem. You mind if I take a stab at the PR? > > > > On Thu, Sep 13, 2018 at 2:20 PM Andy McCright < > j.andrew.mccri...@gmail.com > > > > > wrote: > > > > > 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 < > ja...@carmanconsulting.com > > > > > > 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 < > > > j.andrew.mccri...@gmail.com > > > > > > > > > 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 < > > > 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 > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
