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