You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by James Carman <ja...@carmanconsulting.com> on 2018/09/08 13:00:12 UTC
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
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.3000809@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
>>
>>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
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
On Fri, Sep 14, 2018 at 5:35 AM Andrei Shakirin <as...@talend.com>
wrote:
> Hi 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-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Donnerstag, 13. September 2018 00:51
> > To: users@cxf.apache.org
> > 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.
> > 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....@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
> > > > <james@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 <
> > > james@carmanconsulting.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> I found a thread about this topic from 2015, but it seems to be
> > > talking
> > > > >> about client-side:
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.ap
> > > ache.org_mod-5Fmbox_cxf-2Dusers_201504.mbox_-
> > 253C552BED6B.3000809-40gm
> > > ail.com-
> > 253E&d=DwIBaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm
> > > -lcbhtB3cv08OlIr0lkKR4&m=LtVUiAWp616aAPUnohJFxm_7-
> > hgmuQHkcURHKrhRpBI&s
> > > =aRsXwOJ2jihkyx9DqweSVqU5t3C9TwVls5OwhTdDPZk&e=
> > > > >>
> > > > >> 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
> > > > >>
> > > > >>
> > > >
> > >
> 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/>
>
>
>
RE: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by Andrei Shakirin <as...@talend.com>.
Hi 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-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Donnerstag, 13. September 2018 00:51
> To: users@cxf.apache.org
> 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.
> 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....@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
> > > <james@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 <
> > james@carmanconsulting.com
> > > >
> > > > wrote:
> > > >
> > > >> I found a thread about this topic from 2015, but it seems to be
> > talking
> > > >> about client-side:
> > > >>
> > > >>
> > > >>
> > >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.ap
> > ache.org_mod-5Fmbox_cxf-2Dusers_201504.mbox_-
> 253C552BED6B.3000809-40gm
> > ail.com-
> 253E&d=DwIBaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm
> > -lcbhtB3cv08OlIr0lkKR4&m=LtVUiAWp616aAPUnohJFxm_7-
> hgmuQHkcURHKrhRpBI&s
> > =aRsXwOJ2jihkyx9DqweSVqU5t3C9TwVls5OwhTdDPZk&e=
> > > >>
> > > >> 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
> > > >>
> > > >>
> > >
> >
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/>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
I also created a branch of my project which uses the local version of CXF
3.3.0-SNAPSHOT with my changes in it. I am able to use
ContainerRequestContext and I no longer have to set the property! W00T!
https://github.com/jaxxy-rs/jaxxy/tree/cxf-3.3.0-snapshot
Thanks for taking the time to help, Andy!
On Thu, Sep 13, 2018 at 6:50 PM James Carman <ja...@carmanconsulting.com>
wrote:
> 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....@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.mccright@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 <
>> james@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.mccright@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 <
>> > > james@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 <
>> > > > james@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 <
>> > > > > james@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.3000809@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
>> > > > > > >>
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
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....@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.mccright@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 <
> james@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.mccright@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 <
> > > james@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 <
> > > > james@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 <
> > > > > james@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.3000809@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
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
I created two JIRAs:
https://jira.apache.org/jira/browse/CXF-7842
https://jira.apache.org/jira/browse/CXF-7843
I listed them both as bugs, but we may want to change 7843 to an
"improvement" or something maybe? I don't know. I am working on 7842 now.
On Thu, Sep 13, 2018 at 3:41 PM Andy McCright <j....@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.mccright@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 <
> james@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.mccright@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 <
> > > james@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 <
> > > > james@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 <
> > > > > james@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.3000809@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
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by Andy McCright <j....@gmail.com>.
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.mccright@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 <james@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.mccright@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 <
> > james@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 <
> > > james@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 <
> > > > james@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.3000809@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
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
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....@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.mccright@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 <
> james@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 <
> > james@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 <
> > > james@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.3000809@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
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by Andy McCright <j....@gmail.com>.
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.mccright@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 <
> james@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 <
> > james@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.3000809@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
> > > >>
> > > >>
> > >
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by James Carman <ja...@carmanconsulting.com>.
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....@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 <james@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 <
> james@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.3000809@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
> > >>
> > >>
> >
>
Re: ContainerRequestContext.getHeaders() Returns Concatenated Values?
Posted by Andy McCright <j....@gmail.com>.
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 <james@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.3000809@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
> >>
> >>
>