On 15/05/13 19:22, Alan Bateman wrote:
On 15/05/2013 18:09, Chris Hegarty wrote:
The change looks fine to me.
-Chris
On 15 May 2013, at 17:33, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
This is the webrev for the bug
http://cr.openjdk.java.net/~michaelm/8012625/webrev.1
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.mcma...@oracle.com> wrote:
>
On 15/05/2013 18:09, Chris Hegarty wrote:
The change looks fine to me.
-Chris
On 15 May 2013, at 17:33, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
This is the webrev for the bug
http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/
Thanks
Michael
The fix looks okay to
The change looks fine to me.
-Chris
On 15 May 2013, at 17:33, Michael McMahon 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 ag
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 th
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 Ex
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
Transf
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
Thank you very much for clarification!
Best regards,
Piotr
On Tue, May 7, 2013 at 4: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
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 a
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?
When I debug the code (using the test case I attach
Hi Piotr,
Your bug is accessible at
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 (!checkReus
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
13 matches
Mail list logo
