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 <mailto: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>
<mailto: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>
<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
