RFR [12] 8211437: java.net.http.HttpClient hangs on 204 reply without Content-length 0

[Michael McMahon]

Updated webrev for this at 
http://cr.openjdk.java.net/~michaelm/8211437/webrev.2/index.html
based on feedback below.

I also made a change to the com.sun httpserver. It changes the recent 
fix related to the same
issue such that by default the server will not send a content-length 
back, if the user explicitly
sets one, then it will be sent. This is useful for testing this fix here.

Thanks,

Michael

On 15/10/2018, 16:07, Michael McMahon wrote:
> Hi Daniel,
>
> On 15/10/2018, 12:53, Daniel Fuchs wrote:
>> Hi Michael,
>>
>> On 15/10/2018 11:54, Michael McMahon wrote:
>>> Could I get the following fix reviewed please.
>>>
>>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html
>>
>> Looks good in general.
>>
>> In MultiExchange.java:
>>
>> 236             T nullBody = cf.get();
>>
>> Though technically the body should be available by the
>> time we reach this line, since you completed the subscriber
>> just before, we can't really make any assumption on the
>> implementation of the subscriber.
>>
>> So for the sake of robustness we should probably use
>> getBody().handle(...) to complete `result`
>> rather than calling cf.get();
>>
>
> Yes, that would be better.
>
>>
>> Also I wonder what should happen if a body is present:
>>
>> Should we simply read it instead?
>> Because if we don't then we should close the connection (HTTP/1.1)
>> or reset the stream (HTTP/2) - which probably means getting back
>> to the concrete  exchange implementation to make sure that
>> happens.
>>
>
> I see that as a protocol error. So, rather than attempting to read the
> body, I think we should ensure that the request fails (which it does
> if a content length or transfer encoding field is present). The 
> connection
> also needs to be closed (or stream reset) which I need to check is 
> being done.
>
> Thanks,
> Michael
>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Thanks,
>>>
>>> Michael.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181018/303a6eed/attachment.html>