Hi Andre,
I meant to stop writing, not closing the socket. Poor choice of words,
apologies.
André Warnier wrote:
Taylan Develioglu wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
No, you'd need to modify the source. It's not particularly useful i
Taylan Develioglu wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
No, you'd need to modify the source. It's not particularly useful in
most scenarios to intentionally stall an HTTP conversation, so it's not
a built-in feature :)
No, I'm saying that
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
No, you'd need to modify the source. It's not particularly useful in
most scenarios to intentionally stall an HTTP conversation, so it's not
a built-in feature :)
No, I'm saying that you should send exactly
Hi Chris,
Raising the keepalive-timeout value on the connector definitely improves
the situation.
From what I've gathered from what people posted here (thanks guys) and
dumping packets I believe the situation to be somewhat as follows:
With nagle's off, IE sends out the http request in two
cat w/apr data lost in http post request?
Can MSIE even control which data goes in which packet?
TCP/IP APIs on most platforms allow the Nagle algorithm to be disabled, which
will cause data to be sent out on each call. Most TCP/IP stacks also set the
push flag on the last packet
distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> To: users@tomcat.apache.org
> From: oliver.scho...@capgemini-sdm.com
> Subject: Re: tomcat w/apr data lost in http post request?
> Date: Thu, 12 Ma
Christopher Schultz wrote:
Can MSIE even control which data goes in which packet? That would seem
to be part of the TCP/IP stack, buried in the OS, and affecting both
MSIE and any other browser on the same system.
We saw that Firefox uses only one packet to send a POST request (of
resonabl
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: tomcat w/apr data lost in http post request?
>
> Can MSIE even control which data goes in which packet?
TCP/IP APIs on most platforms allow the Nagle algorithm to be disabled, which
will cause data to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver,
On 3/10/2009 2:41 PM, Oliver Schoett wrote:
> As far as I know, splitting header and body of POST requests into
> separate TCP packets is a peculiarity of IE browsers. This observation
> was made using normal HTML forms, but it may well apply
Taylan Develioglu wrote:
I would like to correct this, it seems to only happen with IE6/7.. maybe
old firefox 2.0
We recently observed a similar problem. When IE 6/7/8 make a form POST,
they often send the header in one TCP packet and the body in another. A
flaky networking component at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/6/2009 4:05 AM, Taylan Develioglu wrote:
> James, thank you very much.
>
> I suspected IE to be guilty because it was happening only with IE clients.
>
> Chris, I guess we don't need to try and reproduce this anymore now we
> know the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/5/2009 5:45 AM, Taylan Develioglu wrote:
> Can the wget clone do this without modification, or do I need to change it?
No, you'd need to modify the source. It's not particularly useful in
most scenarios to intentionally stall an HTTP con
James, thank you very much.
I suspected IE to be guilty because it was happening only with IE clients.
Chris, I guess we don't need to try and reproduce this anymore now we
know the cause?
James Wang wrote:
Hi All,
That's caused by the IE keep-alive bug, Please refer to my previous post :
Hi All,
That's caused by the IE keep-alive bug, Please refer to my previous post :
question : encounter java.net.SocketTimeoutException: Read timed out
occasionally
in below URL :
http://www.nabble.com/question-%3A-encounter-java.net.SocketTimeoutException%3A-Read-timed-out-occasionally-td1932660
Can the wget clone do this without modification, or do I need to change it?
So basically you're saying:
Send content larger then content-length. Then close the connection, see
if the post request gets processed?
The ajax requests may be done over a seperate connection, but all
subsequent req
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/3/2009 2:07 PM, Taylan Develioglu wrote:
> I can reproduce it on demand with our application, but I wouldn't know
> how to create a post request that would stall, the servlet can stall the
> response, but isn't processing of the request (
Taylan,
just a thought:
I do know that there is an issue when *downloading* data such as pdf
etc. via IE over SSL.
Therefore, and since otherb browsers don't seem to be affected, maybe
it's another side-effekt of IE's SSL-*sic*-implementation?
Rgds
Gregor
--
just because your paranoid, doesn't
o:ch...@christopherschultz.net]
Sent: dinsdag 3 maart 2009 18:53
To: Tomcat Users List
Subject: Re: tomcat w/apr data lost in http post request?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/3/2009 12:11 PM, Taylan Develioglu wrote:
> Thanks for the thoughts Chris, but I found the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/3/2009 12:11 PM, Taylan Develioglu wrote:
> Thanks for the thoughts Chris, but I found the cause.
>
> I had lowered the the keepalivetimeout setting to 10s because our
> application polls in 2.5s intervals, pretty unexpected result (I fi
Thanks for the thoughts Chris, but I found the cause.
I had lowered the the keepalivetimeout setting to 10s because our
application polls in 2.5s intervals, pretty unexpected result (I figured
10s should be enough).
I think the connection gets closed somewhere in the middle of the post
request b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/3/2009 8:32 AM, Taylan Develioglu wrote:
> That's a very interesting point there you make regarding the
> content-type. I am not sure why we are using it that way because it's a
> normal post that's being done. Could it be that this is ca
I would like to correct this, it seems to only happen with IE6/7.. maybe
old firefox 2.0
> It happens with different clients indeed.
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-
Hi Andre,
We are sure because we wrote the ajax application that sends the
requests. Or in other words, they should be . (/dispatch does not get
called any other way by the app).
That's a very interesting point there you make regarding the
content-type. I am not sure why we are using it that way
Hi Gregor,
It happens with different clients indeed.
We have redirectport="443" to a another connector yes, but how could
this be of influence on regular http requests?
Is disableUploadTimeout a supported option for the apr connector? The
documentation only mentions it under the HTTP connector.
Hi.
Why are you sure that both the examples you are providing are POST
requests ?
(I am not saying they are not, but the "request method" does not appear
in the logs below, nor does the full URL).
Also, referring to this
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.
Just a shot from the hip:
Have you tried
disableUploadTimeout="true"
within your connector?
Since you're using SSL:
Does it happen with different clients (Firefox, IE6,7,8) or just one
specific client?
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp:
26 matches
Mail list logo
