The change looks fine to me. -Chris
On 15 May 2013, at 17:33, Michael McMahon <michael.x.mcma...@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.hega...@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.hega...@oracle.com >>>>>> <mailto:chris.hega...@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 >
