Trying it right now... Will send a PR if it works
On 12 December 2013 15:36, Ignasi Barrera <[email protected]> wrote: > I found this comment [1] in the Jersey issue, explaining that in SSL > there is an HTTPS URL connection wrapping the actual HttpURLConnection > where the method should be set. > Could you do a quick test and add the appropriate bits from the code > in the Jersey issue and see if that does the trick for HTTPS > connections? > > > [1] > https://java.net/jira/browse/JERSEY-639?focusedCommentId=370981&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_370981 > > On 12 December 2013 15:30, Everett Toews <[email protected]> wrote: >> Yes. The request is going to https://ord.queues.api.rackspacecloud.com. >> >> There's some special handling for HTTPS [1] but the part for setting the >> request method seems to be common for both HTTP and HTTPS. >> >> What did you have in mind? >> >> Everett >> >> [1] >> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L158 >> >> >> On Dec 12, 2013, at 2:29 AM, Ignasi Barrera wrote: >> >>> This is strange. The reflection fix is the same used in the Jersey >>> client [1], and it is supposed to work. >>> Looking at the jclouds code, there is no special handling for HTTPS >>> connections. Everett, are you using an HTTPS one? >>> >>> >>> >>> [1] https://java.net/jira/browse/JERSEY-639 >>> >>> On 12 December 2013 09:09, Andrew Phillips <[email protected]> wrote: >>>>> I know that HttpURLConnection.setRequest() [2] doesn't allow PATCH. I >>>>> also know that we work around this in jclouds by setting the field by >>>>> reflection [3]. >>>> >>>> >>>> Have you been able to try this with the apachehc [1] driver? Does that make >>>> any difference? >>>> >>>> ap >>>> >>>> [1] https://github.com/jclouds/jclouds/tree/master/drivers/apachehc >>
