You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andy McCright <j....@gmail.com> on 2017/07/14 15:36:02 UTC
Enable reflective use of HttpURLConnection by default?
Hi All,
With more and more people using different HTTP methods (verbs) with the
JAX-RS client - particularly PATCH, but really any method they want - is
there any objection to making the "use.httpurlconnection.method.reflection"
true by default in CXF 3.2.X?
Here is some background:
Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
TRACE - if any other HTTP method is passed in, then the caller will get a
ProtocolException.
This is very limiting and prevents users for invoking increasingly common
HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
would alter the list of allows HTTP methods (or provide a mechanism for
users to specify a whitelist of allowed methods), but at best that won't
occur until Java 9.
CXF worked around this problem by adding the
"use.httpurlconnection.method.reflection" property - this can be set as a
system property or as a property on the Message object. When true, CXF
will reflectively modify the state of the HttpURLConnection object
(bypassing the setRequestMethod's parameter check) and set the user's
specified HTTP method.
With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
more users will want to use HTTP methods not in the JDK's current
whitelist. Rather than asking them to set this property, I think it might
make more sense to enable the property by default (they could always
disable if they feel it is a risk).
Any thoughts? If there are no objections, I can make the change.
Thanks,
Andy
Re: Enable reflective use of HttpURLConnection by default?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
Thanks for the explanation too.
I've no objections to enabling this property by default. I guess it can
be reviewed again later on if Java 9 (and JPMS) are used.
May be lets wait for a couple of days for Dan, Alessio others to respond,
I agree it is very reasonable to expect that various HTTP verbs just
work with CXF clients...
Sergey
On 17/07/17 23:28, Andy McCright wrote:
> Hi Sergey,
>
> Thanks for the suggestion. I'll definitely give cxf-rt-transports-http-hc
> a try.
>
> As for what will happen in Java 9 with using reflection, it will work by
> default now that Oracle has decided to ship with the "kill-switch" enabled
> (i.e. the JPMS module system will be disabled by default). However, if a
> user were to enable JPMS, then this reflection approach would also fail.
> So wrt to this transport, PATCH and other "non-standard" HTTP methods will
> not work with JPMS enabled. Given that, your suggestion to use Apache HTTP
> Client makes more sense. Still, I'll plan to change the default for 3.2 to
> use reflection unless anybody objects.
>
> Thanks again,
>
> Andy
>
> On Sat, Jul 15, 2017 at 11:38 AM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
>
>> Hi Andy
>>
>> Note that the other alternative is to use CXF Apache HTTP Client based
>> conduit, cxf-rt-transports-http-hc, if it is on the classpath then CXF
>> (Dan did it) will use HttpClient by default, and as far as I recall (I've
>> no editor opened right now) CXF RS Client (in AbstractClient code)
>> will instruct whatever HTTP conduit is loaded to run a non-async request
>> synchronously.
>>
>> Have you tried cxf-rt-transports-http-hc ? My understanding CXF RS async
>> requests (those part of 2.0 API for ex) can only be truly async when this
>> conduit is loaded.
>>
>> Dan can provide more info but I believe when the async requests run over
>> the HttpUrlConnection CXF may be blocking the thread (at the sync HTTP
>> Conduit level) and using the internal pool, something like that...
>>
>> As far as enabling the reflective use of HttpUrlConnection by default: it
>> is probably a good idea indeed.
>> What will happen when CXF is run in a Java 9 VM though ?
>>
>>
>> Thanks, Sergey
>>
>>
>> On 14/07/17 18:36, Andy McCright wrote:
>>
>>> Hi All,
>>>
>>> With more and more people using different HTTP methods (verbs) with the
>>> JAX-RS client - particularly PATCH, but really any method they want - is
>>> there any objection to making the "use.httpurlconnection.method.
>>> reflection"
>>> true by default in CXF 3.2.X?
>>>
>>> Here is some background:
>>> Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
>>> callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
>>> TRACE - if any other HTTP method is passed in, then the caller will get a
>>> ProtocolException.
>>>
>>> This is very limiting and prevents users for invoking increasingly common
>>> HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
>>> would alter the list of allows HTTP methods (or provide a mechanism for
>>> users to specify a whitelist of allowed methods), but at best that won't
>>> occur until Java 9.
>>>
>>> CXF worked around this problem by adding the
>>> "use.httpurlconnection.method.reflection" property - this can be set as a
>>> system property or as a property on the Message object. When true, CXF
>>> will reflectively modify the state of the HttpURLConnection object
>>> (bypassing the setRequestMethod's parameter check) and set the user's
>>> specified HTTP method.
>>>
>>> With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
>>> more users will want to use HTTP methods not in the JDK's current
>>> whitelist. Rather than asking them to set this property, I think it might
>>> make more sense to enable the property by default (they could always
>>> disable if they feel it is a risk).
>>>
>>> Any thoughts? If there are no objections, I can make the change.
>>>
>>> Thanks,
>>> Andy
>>>
>>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Enable reflective use of HttpURLConnection by default?
Posted by Andy McCright <j....@gmail.com>.
Hi Sergey,
Thanks for the suggestion. I'll definitely give cxf-rt-transports-http-hc
a try.
As for what will happen in Java 9 with using reflection, it will work by
default now that Oracle has decided to ship with the "kill-switch" enabled
(i.e. the JPMS module system will be disabled by default). However, if a
user were to enable JPMS, then this reflection approach would also fail.
So wrt to this transport, PATCH and other "non-standard" HTTP methods will
not work with JPMS enabled. Given that, your suggestion to use Apache HTTP
Client makes more sense. Still, I'll plan to change the default for 3.2 to
use reflection unless anybody objects.
Thanks again,
Andy
On Sat, Jul 15, 2017 at 11:38 AM, Sergey Beryozkin <sb...@gmail.com>
wrote:
> Hi Andy
>
> Note that the other alternative is to use CXF Apache HTTP Client based
> conduit, cxf-rt-transports-http-hc, if it is on the classpath then CXF
> (Dan did it) will use HttpClient by default, and as far as I recall (I've
> no editor opened right now) CXF RS Client (in AbstractClient code)
> will instruct whatever HTTP conduit is loaded to run a non-async request
> synchronously.
>
> Have you tried cxf-rt-transports-http-hc ? My understanding CXF RS async
> requests (those part of 2.0 API for ex) can only be truly async when this
> conduit is loaded.
>
> Dan can provide more info but I believe when the async requests run over
> the HttpUrlConnection CXF may be blocking the thread (at the sync HTTP
> Conduit level) and using the internal pool, something like that...
>
> As far as enabling the reflective use of HttpUrlConnection by default: it
> is probably a good idea indeed.
> What will happen when CXF is run in a Java 9 VM though ?
>
>
> Thanks, Sergey
>
>
> On 14/07/17 18:36, Andy McCright wrote:
>
>> Hi All,
>>
>> With more and more people using different HTTP methods (verbs) with the
>> JAX-RS client - particularly PATCH, but really any method they want - is
>> there any objection to making the "use.httpurlconnection.method.
>> reflection"
>> true by default in CXF 3.2.X?
>>
>> Here is some background:
>> Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
>> callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
>> TRACE - if any other HTTP method is passed in, then the caller will get a
>> ProtocolException.
>>
>> This is very limiting and prevents users for invoking increasingly common
>> HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
>> would alter the list of allows HTTP methods (or provide a mechanism for
>> users to specify a whitelist of allowed methods), but at best that won't
>> occur until Java 9.
>>
>> CXF worked around this problem by adding the
>> "use.httpurlconnection.method.reflection" property - this can be set as a
>> system property or as a property on the Message object. When true, CXF
>> will reflectively modify the state of the HttpURLConnection object
>> (bypassing the setRequestMethod's parameter check) and set the user's
>> specified HTTP method.
>>
>> With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
>> more users will want to use HTTP methods not in the JDK's current
>> whitelist. Rather than asking them to set this property, I think it might
>> make more sense to enable the property by default (they could always
>> disable if they feel it is a risk).
>>
>> Any thoughts? If there are no objections, I can make the change.
>>
>> Thanks,
>> Andy
>>
>>
Re: Enable reflective use of HttpURLConnection by default?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
Note that the other alternative is to use CXF Apache HTTP Client based
conduit, cxf-rt-transports-http-hc, if it is on the classpath then CXF
(Dan did it) will use HttpClient by default, and as far as I recall
(I've no editor opened right now) CXF RS Client (in AbstractClient code)
will instruct whatever HTTP conduit is loaded to run a non-async request
synchronously.
Have you tried cxf-rt-transports-http-hc ? My understanding CXF RS async
requests (those part of 2.0 API for ex) can only be truly async when
this conduit is loaded.
Dan can provide more info but I believe when the async requests run over
the HttpUrlConnection CXF may be blocking the thread (at the sync HTTP
Conduit level) and using the internal pool, something like that...
As far as enabling the reflective use of HttpUrlConnection by default:
it is probably a good idea indeed.
What will happen when CXF is run in a Java 9 VM though ?
Thanks, Sergey
On 14/07/17 18:36, Andy McCright wrote:
> Hi All,
>
> With more and more people using different HTTP methods (verbs) with the
> JAX-RS client - particularly PATCH, but really any method they want - is
> there any objection to making the "use.httpurlconnection.method.reflection"
> true by default in CXF 3.2.X?
>
> Here is some background:
> Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
> callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
> TRACE - if any other HTTP method is passed in, then the caller will get a
> ProtocolException.
>
> This is very limiting and prevents users for invoking increasingly common
> HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
> would alter the list of allows HTTP methods (or provide a mechanism for
> users to specify a whitelist of allowed methods), but at best that won't
> occur until Java 9.
>
> CXF worked around this problem by adding the
> "use.httpurlconnection.method.reflection" property - this can be set as a
> system property or as a property on the Message object. When true, CXF
> will reflectively modify the state of the HttpURLConnection object
> (bypassing the setRequestMethod's parameter check) and set the user's
> specified HTTP method.
>
> With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
> more users will want to use HTTP methods not in the JDK's current
> whitelist. Rather than asking them to set this property, I think it might
> make more sense to enable the property by default (they could always
> disable if they feel it is a risk).
>
> Any thoughts? If there are no objections, I can make the change.
>
> Thanks,
> Andy
>