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
>

Reply via email to