You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jo...@wellsfargo.com on 2016/08/31 15:50:25 UTC
Why is Tomcat sending "Connection: close?"
All,
I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
Thanks
John
Here is my connector config:
<Connector port="7124"
protocol="HTTP/1.1"
SSLEnabled="true"
maxThreads="80"
maxKeepAliveRequests="100"
keepAliveTimeout="10000"
scheme="https"
secure="true"
clientAuth="true"
sslProtocol="TLS"
sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
keystoreFile="${keystoreFile}"
keystorePass="${keystorePassword}"
keyAlias="test"
truststoreFile="${truststoreFile}"
truststorePass="${truststorePassword}"
allowUnsafeLegacyRenegotiation="false"
ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_
CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES
_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_
ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC
DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT
H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C
BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH
_AES_256_CBC_SHA"
/>
Re: Why is Tomcat sending "Connection: close?"
Posted by Rallavagu <ra...@gmail.com>.
One thing I would check is if it is Tomcat that is sending it or an
intermediary load balancer.
On 8/31/16 8:50 AM, John.E.Gregg@wellsfargo.com wrote:
> All,
>
> I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
>
> In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
>
> Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
>
> Thanks
>
> John
>
> Here is my connector config:
>
> <Connector port="7124"
> protocol="HTTP/1.1"
> SSLEnabled="true"
> maxThreads="80"
> maxKeepAliveRequests="100"
> keepAliveTimeout="10000"
> scheme="https"
> secure="true"
> clientAuth="true"
> sslProtocol="TLS"
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
> keystoreFile="${keystoreFile}"
> keystorePass="${keystorePassword}"
> keyAlias="test"
> truststoreFile="${truststoreFile}"
> truststorePass="${truststorePassword}"
> allowUnsafeLegacyRenegotiation="false"
> ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_
> CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES
> _128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_
> ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC
> DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT
> H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C
> BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH
> _AES_256_CBC_SHA"
> />
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is Tomcat sending "Connection: close?"
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
On 8/31/16 12:50 PM, John.E.Gregg@wellsfargo.com wrote:
> No, unfortunately not. I put "%{Connection}i %{Connection}o" in
> the log config and get "Keep-Alive close." IOW the client sends
> Keep-Alive but Tomcat responds with close.
Can you give us a dump of the protocol trace fr one of these
conversations?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXx0mHAAoJEBzwKT+lPKRY4kQQAIoOT/RJ98dgCly6mPcNiYhq
dYMRlDFK8NBROINtM+kaIowxPAF6yXoSp4rmzGPYE/3nDzAmi2Wm+3ig2oqlxm9f
rKQupXUbXbfZbPTN0zZF4UQfaVWeqhUQWux4JVkRR1UFQRu2BxBsX8uFRR7+/Wez
J/Y/Cm3WKDQFO3WlyOsIlNhX4Tnpr77Eb10l2+do3M6cAXEcW+Ao/I4CamEwDtWI
z7dLljT/EzaPQUHnzLFRMpMj/PlkVNL8phuidr3/f3aIgC0laYdZybVgrccQXkoS
vQLkVSnuWaJ9c6z92jfjhg5RAzlFj2KqaVcs5tYZ9LTx2iYQFTMdpfOMFgiIHI52
HikLHXoDEV3zrNRof3VvjaYdgVG9RL9u9anhdVGEVRmXD2JCMc+YKncqhnIimLZd
1dPEZa+kD8ysJ+GoPb66vUoT2FzXAMCDH40Aer98tbEHkYbqQLBXkJBDLi5C/YiS
FNashWtzpzj5pTbhmr5XZq1AtdLnkgoU3h25LeRZ3lsqtJ0CsJKKUVnChGsipfJd
Z0gXxEuP6K/ts5rkG46jnoah8Bls0/KvqyWLlh0omX4Jk5JbOODHeeBSG9qF9crB
Q0qUo05ShACXNTrCpkUFLtwW9xbjlwJNMM9vi2IcBjjMmQGdN2RzWYC71hsIv9YG
a9y9D2e0Jk13X9YaorbS
=RHHx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Why is Tomcat sending "Connection: close?"
Posted by Jo...@wellsfargo.com.
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Wednesday, August 31, 2016 5:25 PM
To: users@tomcat.apache.org
Subject: Re: Why is Tomcat sending "Connection: close?"
Hi.
Please do not top-post your responses on this list.
See : http://tomcat.apache.org/lists.html#tomcat-users # 6)
>
>
> -----Original Message-----
> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Wednesday, August 31, 2016 10:53 AM
> To: users@tomcat.apache.org
> Subject: Re: Why is Tomcat sending "Connection: close?"
>
> On 31.08.2016 17:50, John.E.Gregg@wellsfargo.com wrote:
>> All,
>>
>> I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
>>
>> In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
>>
>> Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
>>
>> Thanks
>>
>> John
>>
>> Here is my connector config:
>>
>> <Connector port="7124"
>> protocol="HTTP/1.1"
>> SSLEnabled="true"
>> maxThreads="80"
>> maxKeepAliveRequests="100"
>> keepAliveTimeout="10000"
>> scheme="https"
>> secure="true"
>> clientAuth="true"
>> sslProtocol="TLS"
>> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
>> keystoreFile="${keystoreFile}"
>> keystorePass="${keystorePassword}"
>> keyAlias="test"
>> truststoreFile="${truststoreFile}"
>> truststorePass="${truststorePassword}"
>> allowUnsafeLegacyRenegotiation="false"
>> ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA,
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_
>> CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA,
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA,
>> TLS_DHE_DSS_WITH_AES _128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
>> TLS_ ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH _AES_256_CBC_SHA"
>> />
>>
>
> Sorry to ask, but are you positive that there is *nothing* between the
> browser and Tomcat ? (I mean like a firewall, proxy server, etc..)
>
> > No, unfortunately not. I put "%{Connection}i %{Connection}o" in the
> > log config and get
"Keep-Alive close." IOW the client sends Keep-Alive but Tomcat responds with close.
>
There are a number of scenarios in which a webserver - not only Tomcat - would send a
"Connection: close" header in a response, and close the connection after sending the response. For the gory details, see https://tools.ietf.org/html/rfc7230#section-6.3 etc..
Simplified :
- if a webserver knows in advance the size of the response body, then it would normally send a "Content-length: xxx" header, followed by a response body of exactly that length.
In such a case also, it should normally honor the keep-alive request of the client, and not close the connection
- if the server does not know in advance the size of the response body (e.g. it is generated dynamically by a script or servlet or such), then it cannot send a Content-length header in advance, and it has 2 choices :
a) use a "Transfer-encoding: chunked" method, whereby the response body is "packaged"
in successive "chunks", each with a header giving its chunk length, the sequence being terminated by a zero-length chunk (which tells the client that this response is finished)
or
b) if it cannot use (or is forbidden to use) the above for some reason, then the only way is to send the response body as it arrives from whatever generates it, and when that body ends, and it has sent the whole body to the client, close the connection.
The closing of the connection then acts for the client as a signal that the response to this request is finished (as there would be no way for the client otherwise to know if there is more to come or not).
In such a case, if the webserver were to know in advance that this is the case (before sending the first chunk of the response body to the client), it would be good practice for the server to also send a "Connection: close" in the headers of the response.
So, assuming at first that there is no related bug in the Tomcat 7 code, would it be conceivable that the webapp would somehow generate its response in such a way that
a) Tomcat does not know in advance the size of that response
and
b) Tomcat is prevented from using the "Content-encoding: chunked" method ?
I found for example this which might be relevant :
http://stackoverflow.com/questions/6299432/how-do-disable-transfer-encoding-in-tomcat-6
Thanks André.
It turns out that the developers have a config value that specifically sets "Connection: close." I didn't understand their explanation for when it's set and not set, but they say it's typically not set. IOW, persistent connections are usually allowed. Unfortunately it's been set incorrectly, which causes the load tests to fail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is Tomcat sending "Connection: close?"
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
Hi.
Please do not top-post your responses on this list.
See : http://tomcat.apache.org/lists.html#tomcat-users # 6)
>
>
> -----Original Message-----
> From: Andr Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Wednesday, August 31, 2016 10:53 AM
> To: users@tomcat.apache.org
> Subject: Re: Why is Tomcat sending "Connection: close?"
>
> On 31.08.2016 17:50, John.E.Gregg@wellsfargo.com wrote:
>> All,
>>
>> I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
>>
>> In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
>>
>> Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
>>
>> Thanks
>>
>> John
>>
>> Here is my connector config:
>>
>> <Connector port="7124"
>> protocol="HTTP/1.1"
>> SSLEnabled="true"
>> maxThreads="80"
>> maxKeepAliveRequests="100"
>> keepAliveTimeout="10000"
>> scheme="https"
>> secure="true"
>> clientAuth="true"
>> sslProtocol="TLS"
>> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
>> keystoreFile="${keystoreFile}"
>> keystorePass="${keystorePassword}"
>> keyAlias="test"
>> truststoreFile="${truststoreFile}"
>> truststorePass="${truststorePassword}"
>> allowUnsafeLegacyRenegotiation="false"
>> ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA,
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_ CBC_SHA,
>> SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
>> SSL_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES _128_CBC_SHA,
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_
>> ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH _AES_256_CBC_SHA"
>> />
>>
>
> Sorry to ask, but are you positive that there is *nothing* between the browser and Tomcat ? (I mean like a firewall, proxy server, etc..)
>
> > No, unfortunately not. I put "%{Connection}i %{Connection}o" in the log config and get
"Keep-Alive close." IOW the client sends Keep-Alive but Tomcat responds with close.
>
There are a number of scenarios in which a webserver - not only Tomcat - would send a
"Connection: close" header in a response, and close the connection after sending the
response. For the gory details, see https://tools.ietf.org/html/rfc7230#section-6.3 etc..
Simplified :
- if a webserver knows in advance the size of the response body, then it would normally
send a "Content-length: xxx" header, followed by a response body of exactly that length.
In such a case also, it should normally honor the keep-alive request of the client, and
not close the connection
- if the server does not know in advance the size of the response body (e.g. it is
generated dynamically by a script or servlet or such), then it cannot send a
Content-length header in advance, and it has 2 choices :
a) use a "Transfer-encoding: chunked" method, whereby the response body is "packaged"
in successive "chunks", each with a header giving its chunk length, the sequence being
terminated by a zero-length chunk (which tells the client that this response is finished)
or
b) if it cannot use (or is forbidden to use) the above for some reason, then the only
way is to send the response body as it arrives from whatever generates it, and when that
body ends, and it has sent the whole body to the client, close the connection.
The closing of the connection then acts for the client as a signal that the response to
this request is finished (as there would be no way for the client otherwise to know if
there is more to come or not).
In such a case, if the webserver were to know in advance that this is the case (before
sending the first chunk of the response body to the client), it would be good practice for
the server to also send a "Connection: close" in the headers of the response.
So, assuming at first that there is no related bug in the Tomcat 7 code, would it be
conceivable that the webapp would somehow generate its response in such a way that
a) Tomcat does not know in advance the size of that response
and
b) Tomcat is prevented from using the "Content-encoding: chunked" method ?
I found for example this which might be relevant :
http://stackoverflow.com/questions/6299432/how-do-disable-transfer-encoding-in-tomcat-6
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Why is Tomcat sending "Connection: close?"
Posted by Jo...@wellsfargo.com.
No, unfortunately not. I put "%{Connection}i %{Connection}o" in the log config and get "Keep-Alive close." IOW the client sends Keep-Alive but Tomcat responds with close.
Thanks
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Wednesday, August 31, 2016 10:53 AM
To: users@tomcat.apache.org
Subject: Re: Why is Tomcat sending "Connection: close?"
On 31.08.2016 17:50, John.E.Gregg@wellsfargo.com wrote:
> All,
>
> I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
>
> In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
>
> Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
>
> Thanks
>
> John
>
> Here is my connector config:
>
> <Connector port="7124"
> protocol="HTTP/1.1"
> SSLEnabled="true"
> maxThreads="80"
> maxKeepAliveRequests="100"
> keepAliveTimeout="10000"
> scheme="https"
> secure="true"
> clientAuth="true"
> sslProtocol="TLS"
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
> keystoreFile="${keystoreFile}"
> keystorePass="${keystorePassword}"
> keyAlias="test"
> truststoreFile="${truststoreFile}"
> truststorePass="${truststorePassword}"
> allowUnsafeLegacyRenegotiation="false"
> ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_ CBC_SHA,
> SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES _128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_
> ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH _AES_256_CBC_SHA"
> />
>
Sorry to ask, but are you positive that there is *nothing* between the browser and Tomcat ? (I mean like a firewall, proxy server, etc..)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is Tomcat sending "Connection: close?"
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 31.08.2016 17:50, John.E.Gregg@wellsfargo.com wrote:
> All,
>
> I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection: close" in the response header as often as it is. With almost no load on the server, I get "Connection: close" pretty much every time. The client is sending "Connection: keep-alive" but it doesn't seem to matter. HTTP protocol is 1.1 and response code is 200.
>
> In other cases I've seen Tomcat behave exactly the way the doc says the below config should behave (100 requests per connection as long as the timeout is not exceeded) but not this time.
>
> Any idea why this is occurring or where to look to debug it? I've tried setting breakpoints in AbstractHttp11Processor where "Connection: close" is set, but it's not hit.
>
> Thanks
>
> John
>
> Here is my connector config:
>
> <Connector port="7124"
> protocol="HTTP/1.1"
> SSLEnabled="true"
> maxThreads="80"
> maxKeepAliveRequests="100"
> keepAliveTimeout="10000"
> scheme="https"
> secure="true"
> clientAuth="true"
> sslProtocol="TLS"
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello,SSLv3"
> keystoreFile="${keystoreFile}"
> keystorePass="${keystorePassword}"
> keyAlias="test"
> truststoreFile="${truststoreFile}"
> truststorePass="${truststorePassword}"
> allowUnsafeLegacyRenegotiation="false"
> ciphers="SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_
> CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES
> _128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_
> ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_EC
> DSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WIT
> H_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_C
> BC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH
> _AES_256_CBC_SHA"
> />
>
Sorry to ask, but are you positive that there is *nothing* between the browser and Tomcat
? (I mean like a firewall, proxy server, etc..)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org