Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection
Michael McMahon
michael.x.mcmahon at oracle.com
Wed May 15 09:33:04 PDT 2013
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 <mailto: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>
>> <mailto: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>
>> <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>
>> <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/108a7b77/attachment.html
More information about the net-dev
mailing list