Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection
Piotr Bzdyl
piotr at bzdyl.net
Wed May 15 13:16:26 PDT 2013
Thank you again for taking time to look at the issue. The proposed fix will
eliminate the surprise we encountered as there will be no delay when Expect
header and no streaming is used.
Best regards,
Piotr
On Wed, May 15, 2013 at 6:33 PM, 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/b4cf16b0/attachment.html
More information about the net-dev
mailing list