Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection
Chris Hegarty
chris.hegarty at oracle.com
Wed May 15 10:09:49 PDT 2013
The change looks fine to me.
-Chris
On 15 May 2013, at 17:33, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> This is the webrev for the bug
>
> http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/
>
> Thanks
> Michael
>
> On 15/05/13 17:03, Michael McMahon wrote:
>> Piotr,
>>
>> We took a look at this issue again, and while it is still the case that to get Expect: Continue
>> to work properly, you need to enable one of the streaming modes. However, prior to jdk7
>> there was partial support for this mechanism, where it obeyed the protocol at least
>> when you set the Expect header. What it didn't do is delay sending the request body until
>> the 100 response is received. However, that might not have been a problem in many cases,
>> and it looks like in jdk7 this specific mode is not working exactly the same as before. One problem
>> is that a 5 second delay can be seen.
>>
>> Anyhow, we will fix the problem in jdk 8 so that the exact same behavior as jdk 6 is seen.
>> I'll send a webrev with a fix soon.
>>
>> Thanks
>> Michael
>>
>> On 07/05/13 15:40, Piotr Bzdyl wrote:
>>> In this case I will have to double check the SAAJ SoapConnection (as we encountered the problem indirectly when using SAAJ SoapConnection). The code invoking the SOAP service was setting Expect: 100-continue header as the SOAP message header and SoapConnection propagated it to HttpURLConnection. I need to confirm that it is even allowed and if it is I will report the bug in SAAJ project.
>>>
>>> Best regards,
>>> Piotr
>>>
>>> On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>> I replied too quick. This is not a bug per say, but a limitation of the existing API.
>>>>
>>>> Expect: 100-continue is only supported with streaming requests, i.e. setChunkedStreamingMode(int), or setFixedLengthStreamingMode(long).
>>>>
>>>> With the above API's the appropriate header, content-length or Transfer-Encoding: chunked, can be set before return the OutputStream ( from getOutputStream() ). Without either of the above calls the content-length is only determinable after the returned output stream is closed, and this happens after the return from getOutptuStream().
>>>>
>>>> So I would say this is a limitation of the API. But the workaround is quite straight forward, use streaming.
>>>>
>>>> -Chris.
>>>>
>>>>
>>>> On 05/07/2013 03:05 PM, Chris Hegarty wrote:
>>>>> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote:
>>>>>> Chris,
>>>>>>
>>>>>> When I used the URL provided by you I have indeed access to my bug
>>>>>> report. It seems the notification email I got with confirmation of my
>>>>>> report submission provides the misleading URL. Is it possible to fix it
>>>>>> in the notification template?
>>>>>
>>>>> You are right the URL provided to you is pretty much useless, at this
>>>>> point. Not that is matters much, but there are separate JIRA projects
>>>>> for bugs moving from web screening to the "real" bug incidents. If it is
>>>>> any consolation, your issue has made it all the way ;-)
>>>>>
>>>>>>
>>>>>> When I debug the code (using the test case I attached to the bug
>>>>>> report), it doesn't go into the
>>>>>>
>>>>>> if (streaming() && strOutputStream == null) {
>>>>>> writeRequests(); // <<<< Here
>>>>>> }
>>>>>>
>>>>>> but goes directly to expect100Continue() in:
>>>>>> if (expectContinue) {
>>>>>> expect100Continue();
>>>>>> }
>>>>>
>>>>> Ah ha. that is the bug. We should always writeRequests ( write headers )
>>>>> when expectContinue is set. I'll update the bug with this clear comment,
>>>>> and then propose a patch for JDK8.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty <chris.hegarty at oracle.com
>>>>>> <mailto:chris.hegarty at oracle.com>> wrote:
>>>>>>
>>>>>> Hi Piotr,
>>>>>>
>>>>>> Your bug is accessible at
>>>>>> http://bugs.sun.com/view_bug.__do?bug_id=8012625
>>>>>> <http://bugs.sun.com/view_bug.do?bug_id=8012625>
>>>>>>
>>>>>> From my reading of the code the headers should be sent before
>>>>>> waiting for the reply to continue.
>>>>>>
>>>>>> From sun/net/www/prtotocol/http/__HttpURLConnection:
>>>>>>
>>>>>> getOutputStream() {
>>>>>> ....
>>>>>> if (!checkReuseConnection())
>>>>>> connect();
>>>>>>
>>>>>> boolean expectContinue = false;
>>>>>> String expects = requests.findValue("Expect");
>>>>>> if ("100-Continue".__equalsIgnoreCase(expects)) {
>>>>>> http.setIgnoreContinue(false);
>>>>>> expectContinue = true;
>>>>>> }
>>>>>>
>>>>>> if (streaming() && strOutputStream == null) {
>>>>>> writeRequests(); // <<<< Here
>>>>>> }
>>>>>>
>>>>>> if (expectContinue) {
>>>>>> expect100Continue();
>>>>>> }
>>>>>> ....
>>>>>>
>>>>>> }
>>>>>>
>>>>>> Are you seeing something different?
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> This is my first post to this mailing list so I would like to
>>>>>> say "Hi".
>>>>>>
>>>>>> The reason I subscribed and I am writing is that I believe I
>>>>>> have found
>>>>>> a bug in sun.*.HttpURLConnection class (in particular how it
>>>>>> handles
>>>>>> Expect: 100-continue header). I have already submitted a bug at
>>>>>> bugs.sun.com <http://bugs.sun.com> <http://bugs.sun.com> but
>>>>>> after almost 3 weeks I still
>>>>>>
>>>>>> cannot access the bug and check its status
>>>>>> (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773
>>>>>> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001773>).
>>>>>>
>>>>>> I would like to ask if bugs.sun.com <http://bugs.sun.com>
>>>>>> <http://bugs.sun.com> is alive or if
>>>>>>
>>>>>> it is possible to report the bug in the OpenJDK project or is
>>>>>> there any
>>>>>> other alternative procedure for submitting bug reports.
>>>>>>
>>>>>> Best regards,
>>>>>> Piotr Bzdyl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/69ec9f87/attachment.html
More information about the net-dev
mailing list