No idea about a downside. This is a rare case, talking about 80% vs 20%
here, it is also a non-standard HTTP header, hence IMHO having it
affecting what the application code sees (request URI, etc) is disabled
by default.
Cheers, Sergey
On 18/08/15 17:16, James Carman wrote:
Any reason we don't default that forwarded proto setting to true? Is there
a downside?
On Tue, Aug 18, 2015 at 5:05 AM Sergey Beryozkin <sberyoz...@gmail.com>
wrote:
Hi James
Thanks for spotting it, I recall now we fixed it by supporting the init
prefix property which should be recognized by pax-*:
https://issues.apache.org/jira/browse/CXF-6292
and
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=blobdiff;f=rt/transports/http/src/main/resources/OSGI-INF/blueprint/osgiservlet.xml;h=99481fc7e18a05d179cc42035717adbdd89dbdae;hp=b08dbd5209f3a550188887f34e9c235780c0c121;hb=ed2196b4;hpb=566787ec5cc6b9519e575df6434e212ff384c85a
Setting it to "init." will likely affect CXF OSGI users who are not
depending on pax web components which expect the init prefixes.
Can you try the configurable init prefix property and close the pull if
it works for you ?
Thanks, Sergey
On 18/08/15 04:38, James Carman wrote:
Oh, and I created a JIRA also:
https://issues.apache.org/jira/browse/CXF-6547
On Mon, Aug 17, 2015 at 11:37 PM James Carman <
ja...@carmanconsulting.com>
wrote:
Sergey,
I have created a pull request to fix this issue in OSGi:
https://github.com/apache/cxf/pull/82
The issue is that PAX Web changed the init-param detection so that
service
properties must include a prefix in order to be considered to be an
init-param (ask Achim, he did it :). Anyway, merely adding "init."
before
all the params makes them show up.
Thanks,
James
On Sun, Aug 9, 2015 at 2:33 PM Sergey Beryozkin <sberyoz...@gmail.com>
wrote:
Hi
I signed off after the 1st reply...
Is there a chance you can set a breakpoint in
https://fisheye6.atlassian.com/browse/cxf/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/AbstractHTTPServlet.java?r=f5655d81ea6a880cf6b8b1cdcabddf1cd4dbe869#to297
?
I can try a basic test a bit later on too,
Cheers, Sergey
On 07/08/15 18:40, James Carman wrote:
On Fri, Aug 7, 2015 at 12:46 PM Sergey Beryozkin <
sberyoz...@gmail.com>
wrote:
CXFServlet has a "use-x-forwarded-headers" boolean parameter, if it
is
set to true then CXFServlet will check X-FORWARDED-PROTO, I recall
adding the code to support something similar, can you try it, I think
ELB should have these headers set when forwarding
Sergey,
Thanks for the tip! I'm setting it up in Karaf and have verified that
the
config is there:
config:list "(service.pid=org.apache.cxf.osgi)"
----------------------------------------------------------------
Pid: org.apache.cxf.osgi
BundleLocation: mvn:org.apache.cxf/cxf-rt-transports-http/3.0.5
Properties:
felix.fileinstall.filename =
file:/opt/aetos/etc/org.apache.cxf.osgi.cfg
org.apache.cxf.servlet.context = /services
org.apache.cxf.servlet.use-x-forwarded-headers = true
service.pid = org.apache.cxf.osgi
My WADL still has "http" links in it, even though I see these headers
when
I request the WADL:
X-Forwarded-For=[X.X.X.X], X-Forwarded-Port=[443],
X-Forwarded-Proto=[https]
Can you think of anything I'm missing? Could it be that just the WADL
is
borked, but usage of UrlInfo in my JAX-RS resources will work fine?
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
