Re: backupManager - backup on all nodes and slowly
On 02/02/2014 22:59, Ja kub wrote: With below BackupManager backup manager configuration in server.xml heap memory increases over 100MB on each of four nodes in cluster. In addition time of ab -c 10 -n 10 -p post.txt http://localhost:18080/petclinic/session/fill is about 150 seconds with default DeltaManager it is about 15 seconds. Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=6 Manager className=org.apache.catalina.ha.session.BackupManager expireSessionsOnShutdown=false notifyListenersOnReplication=true mapSendOptions=6/ /Cluster What may I be doing wrong ? Are you using sticky sessions on your load balancer? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
Hi. 1. We are aware that 6.0.26 is old, but since there is a large operational impact, we wont upgrade the tomcat until we will know its definetly an issue in this specific version 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread 3. Looking at the sessions manager, we see a lot of sessions with a negative TTL - meaning they werent expired, if I manually expire them then the sessions count decreases. 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? Thanks, On Sun, Feb 2, 2014 at 7:38 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2014-02-02 Maor Yosef maoryo...@gmail.com: Hi, 1. 6.0.26 is old. We are facing issues where the sessions are not being expired and eventually causing a stack overflow. 2. Non-expiring sessions may cause OOM, but they cannot cause a stack overflow. What are your evidences? We see that at some point the sessions get pilled up and we need to manually expire those sessions through the manager application, or until we will restart tomcat but after a few hours / days, sessions will start to get stuck again 3. Increasing count of session does not mean that sessions do not expire. Your evidence = ? We see it in all the applications that are deployed on tomcat, including the manager application - this rules out (in my opinion) the possibility that its an issue with our application. 4. Sessions are expired by a background thread. If the thread is stuck somewhere (e.g. doing auto-deployment work) it will affect expiration of sessions. Your thread dump = ? By default there is one background thread that is shared by all container levels in Tomcat, but you can configure a separate one in each container (container = Context, Host or Engine). 5. Web bots that do not support cookies may generate multiple sessions. See CrawlerSessionManagerValve Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backupManager - backup on all nodes and slowly
I have configured no loadbalancer, I accessed tomcat directly tomcats are on 18080, 28080, 38080, 48080, In browser I used only 18080, this is my laptop test env, nobody else access it, 28080, 38080, 48080, where untouched by broser, but in jvisualvm their memory has increased by the same amount (about 100MB), it was increase after gc . Thx, Jakub On Mon, Feb 3, 2014 at 9:04 AM, Mark Thomas ma...@apache.org wrote: On 02/02/2014 22:59, Ja kub wrote: With below BackupManager backup manager configuration in server.xml heap memory increases over 100MB on each of four nodes in cluster. In addition time of ab -c 10 -n 10 -p post.txt http://localhost:18080/petclinic/session/fill is about 150 seconds with default DeltaManager it is about 15 seconds. Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=6 Manager className=org.apache.catalina.ha.session.BackupManager expireSessionsOnShutdown=false notifyListenersOnReplication=true mapSendOptions=6/ /Cluster What may I be doing wrong ? Are you using sticky sessions on your load balancer? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
On 3 February 2014 09:30, Maor Yosef maoryo...@gmail.com wrote: 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread do you use a 32 bit vm? Because most of the time when i see this i ask the same question, and most of the time that is then true and they have specified quite a high heap size. If you do that then the native part of the memory that a 32 bit process can have is getting small -- Johan Compagner Servoy
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
using 64 bit On Mon, Feb 3, 2014 at 10:51 AM, Johan Compagner jcompag...@servoy.comwrote: On 3 February 2014 09:30, Maor Yosef maoryo...@gmail.com wrote: 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread do you use a 32 bit vm? Because most of the time when i see this i ask the same question, and most of the time that is then true and they have specified quite a high heap size. If you do that then the native part of the memory that a 32 bit process can have is getting small -- Johan Compagner Servoy
Tomcat and Chunked Transfer-Encoding
Hi, We have some weird behaviopur with one of our applications using apache-tomcat-6.0.37. This is the report of the newtork engineer: The application (or app server - apache/coyote) is returning a response with Chunked Transfer-Encoding, but is sending the first chunks before giving the http headers (that defines the chunk-encoding). The result is that the client receives a response stating by the definition on the chunk lenght (7a5), and as the header Content-Encoding has not been received, that length definition is interpreted as response characters. Here is a dump of the communication between TARS Reverse Proxy and the Back-end. (You may notice the response headers - 200 OK - after the first chunk (in blue, starting by 7a5, the length in HEX ) See attached screenshot tcpstream.jpg. Regards Walter This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 09:34, walter.heesterm...@toyota-europe.com wrote: Hi, We have some weird behaviopur with one of our applications using apache-tomcat-6.0.37. This is the report of the newtork engineer: /The application (or app server - apache/coyote) is returning a response with Chunked Transfer-Encoding, but is sending the first chunks before giving the http headers (that defines the chunk-encoding). That strikes me as pretty unlikely given the length of time 6.0.x has been released and the lack of similar reports. It may be possible if the application is doing something it shouldn't, like holding on to a reference to a response object and re-using it across multiple requests. The result is that the client receives a response stating by the definition on the chunk lenght (7a5), and as the header Content-Encoding has not been received, that length definition is interpreted as response characters. Here is a dump of the communication between TARS Reverse Proxy and the Back-end. (You may notice the response headers - 200 OK - after the first chunk (in blue, starting by 7a5, the length in HEX )/ See attached screenshot tcpstream.jpg. This list strips most attachments. Just put the plain text of the HTTP request and response headers in the body of your e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backupManager - backup on all nodes and slowly
On 03/02/2014 08:33, Ja kub wrote: I have configured no loadbalancer, I accessed tomcat directly Both things that it would have been useful to mention in your original question. Before we go any further, how about telling us which Tomcat version you are using? Mark tomcats are on 18080, 28080, 38080, 48080, In browser I used only 18080, this is my laptop test env, nobody else access it, 28080, 38080, 48080, where untouched by broser, but in jvisualvm their memory has increased by the same amount (about 100MB), it was increase after gc . Thx, Jakub - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 6.0.39 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.39 stable. Apache Tomcat 6.0.39 is primarily a security and bug fix release. The notable changes include: - Various improvements to XML configuration file validation. - Better adherence to RFC2616 for Content-Type and Content-Length headers. - Avoid CVE-2013-1571 when generating Javadoc. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Note that is version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for different CPU architectures. Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from earlier releases: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0. Webdav returns 0x80070021
Tomcat 7.047. Default setup form web. Added an webapp with webdav enabled readonly = false; Windows 7: Mapped a drive to the specific folder: View content OK, put creating a new file/folder results in a dialog Localhost logging: 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document.txt HTTP/1.1 207 850 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document%20(2).txt HTTP/1.1 207 864 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document%20(3).txt HTTP/1.1 404 1011 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PUT /webdav/dat1/New%20Text%20Document%20(3).txt HTTP/1.1 409 1001 Anyone familiar with this behavior, or known solutions. Thx in advance, Ruud This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.
Re: Tomcat and Chunked Transfer-Encoding
Hi, I have requested the trext format. In the meantime, how can I disable the 'Chunked Transfer-Encoding' inside Tomcat server? Regards Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 11:15 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 09:34, walter.heesterm...@toyota-europe.com wrote: Hi, We have some weird behaviopur with one of our applications using apache-tomcat-6.0.37. This is the report of the newtork engineer: /The application (or app server - apache/coyote) is returning a response with Chunked Transfer-Encoding, but is sending the first chunks before giving the http headers (that defines the chunk-encoding). That strikes me as pretty unlikely given the length of time 6.0.x has been released and the lack of similar reports. It may be possible if the application is doing something it shouldn't, like holding on to a reference to a response object and re-using it across multiple requests. The result is that the client receives a response stating by the definition on the chunk lenght (7a5), and as the header Content-Encoding has not been received, that length definition is interpreted as response characters. Here is a dump of the communication between TARS Reverse Proxy and the Back-end. (You may notice the response headers - 200 OK - after the first chunk (in blue, starting by 7a5, the length in HEX )/ See attached screenshot tcpstream.jpg. This list strips most attachments. Just put the plain text of the HTTP request and response headers in the body of your e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately.
Re: backupManager - backup on all nodes and slowly
Good question, sorry I didn't tell earlier, its tomcat 7.0.50 on linux, zip or tgz from download page, not from rpm. On Mon, Feb 3, 2014 at 11:17 AM, Mark Thomas ma...@apache.org wrote: On 03/02/2014 08:33, Ja kub wrote: I have configured no loadbalancer, I accessed tomcat directly Both things that it would have been useful to mention in your original question. Before we go any further, how about telling us which Tomcat version you are using? Mark tomcats are on 18080, 28080, 38080, 48080, In browser I used only 18080, this is my laptop test env, nobody else access it, 28080, 38080, 48080, where untouched by broser, but in jvisualvm their memory has increased by the same amount (about 100MB), it was increase after gc . Thx, Jakub - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 10:47, walter.heesterm...@toyota-europe.com wrote: Hi, I have requested the trext format. In the meantime, how can I disable the 'Chunked Transfer-Encoding' inside Tomcat server? You can't. Mark Regards Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 11:15 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 09:34, walter.heesterm...@toyota-europe.com wrote: Hi, We have some weird behaviopur with one of our applications using apache-tomcat-6.0.37. This is the report of the newtork engineer: /The application (or app server - apache/coyote) is returning a response with Chunked Transfer-Encoding, but is sending the first chunks before giving the http headers (that defines the chunk-encoding). That strikes me as pretty unlikely given the length of time 6.0.x has been released and the lack of similar reports. It may be possible if the application is doing something it shouldn't, like holding on to a reference to a response object and re-using it across multiple requests. The result is that the client receives a response stating by the definition on the chunk lenght (7a5), and as the header Content-Encoding has not been received, that length definition is interpreted as response characters. Here is a dump of the communication between TARS Reverse Proxy and the Back-end. (You may notice the response headers - 200 OK - after the first chunk (in blue, starting by 7a5, the length in HEX )/ See attached screenshot tcpstream.jpg. This list strips most attachments. Just put the plain text of the HTTP request and response headers in the body of your e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backupManager - backup on all nodes and slowly
On 03/02/2014 11:03, Ja kub wrote: Good question, sorry I didn't tell earlier, its tomcat 7.0.50 on linux, zip or tgz from download page, not from rpm. OK. Good to know it is the current release. It is probably time to fire up a profiler and see where all the time is being spent. Mark On Mon, Feb 3, 2014 at 11:17 AM, Mark Thomas ma...@apache.org wrote: On 03/02/2014 08:33, Ja kub wrote: I have configured no loadbalancer, I accessed tomcat directly Both things that it would have been useful to mention in your original question. Before we go any further, how about telling us which Tomcat version you are using? Mark tomcats are on 18080, 28080, 38080, 48080, In browser I used only 18080, this is my laptop test env, nobody else access it, 28080, 38080, 48080, where untouched by broser, but in jvisualvm their memory has increased by the same amount (about 100MB), it was increase after gc . Thx, Jakub - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
If it can't be disabled, who is then generating the issue, can it be tomcat issue or issue application relatd, not using correct response? Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 12:10 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 10:47, walter.heesterm...@toyota-europe.com wrote: Hi, I have requested the trext format. In the meantime, how can I disable the 'Chunked Transfer-Encoding' inside Tomcat server? You can't. Mark Regards Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 11:15 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 09:34, walter.heesterm...@toyota-europe.com wrote: Hi, We have some weird behaviopur with one of our applications using apache-tomcat-6.0.37. This is the report of the newtork engineer: /The application (or app server - apache/coyote) is returning a response with Chunked Transfer-Encoding, but is sending the first chunks before giving the http headers (that defines the chunk-encoding). That strikes me as pretty unlikely given the length of time 6.0.x has been released and the lack of similar reports. It may be possible if the application is doing something it shouldn't, like holding on to a reference to a response object and re-using it across multiple requests. The result is that the client receives a response stating by the definition on the chunk lenght (7a5), and as the header Content-Encoding has not been received, that length definition is interpreted as response characters. Here is a dump of the communication between TARS Reverse Proxy and the Back-end. (You may notice the response headers - 200 OK - after the first chunk (in blue, starting by 7a5, the length in HEX )/ See attached screenshot tcpstream.jpg. This list strips most attachments. Just put the plain text of the HTTP request and response headers in the body of your e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately.
Re: backupManager - backup on all nodes and slowly
But time is not such a great problem for me. Time of execution was mentioned only in addition - there are 100 k requests. I am mainly interested in memory, and how BackupManager works. I hoped, that with BackupManager memory will increase on node which is queried and ONLY on one backup node, but here it is increasing on all 4 nodes in cluster. Should BackupManager be working as I write above, or do I understand it wrong ? On Mon, Feb 3, 2014 at 12:13 PM, Mark Thomas ma...@apache.org wrote: On 03/02/2014 11:03, Ja kub wrote: Good question, sorry I didn't tell earlier, its tomcat 7.0.50 on linux, zip or tgz from download page, not from rpm. OK. Good to know it is the current release. It is probably time to fire up a profiler and see where all the time is being spent. Mark On Mon, Feb 3, 2014 at 11:17 AM, Mark Thomas ma...@apache.org wrote: On 03/02/2014 08:33, Ja kub wrote: I have configured no loadbalancer, I accessed tomcat directly Both things that it would have been useful to mention in your original question. Before we go any further, how about telling us which Tomcat version you are using? Mark tomcats are on 18080, 28080, 38080, 48080, In browser I used only 18080, this is my laptop test env, nobody else access it, 28080, 38080, 48080, where untouched by broser, but in jvisualvm their memory has increased by the same amount (about 100MB), it was increase after gc . Thx, Jakub - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
Here the text format of the traffic
GET
/ws/ws_ext?servlet=upload_file_project_attributesfileAttr=CompletedDTPCaptionKitproject=30452token=1358616358random=0.5308450920567584
HTTP/1.1
Host: td3worldserverlb.toyota-europe.com
Accept: text/html, application/xhtml+xml, */*
Accept-Language: nl-NL
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64;
Trident/6.0)
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
X-Forwarded-For: 77.60.99.113
X-Forwarded-Host: mytechdoc.toyota-europe.com
X-Forwarded-Server: mytechdoc.toyota-europe.com
Connection: Keep-Alive
7a5
html
head
titleIdiom WorldServer - File Upload Page/title
link rel='stylesheet' href='style.css' type='text/css'
script language=JavaScript src='general.js'/script
script language=JavaScript src='ips.js'/script
script language=JavaScript
src='ws_ext?servlet=include_proxyfileName=ips.jstoken=1358616358'/script
script
language=JavaScriptlocation.href=location.href+'customopenertoken='+
getOpenerToken();/script
/head
body onload=requestFocus('uploadedFile')
form style=width:100%; height: 100% method=post
table width=100% height=100% cellpadding=5tr height=1%td
class=popup_dialog_headerFile Upload/td/trtr height=100%td
valign=top
iClick on Browse button to browse and select the file to upload.
/ipinput name=uploadedFile value= type=file input
name=fileAttr value=CompletedDTPCaptionKit type=hidden input
name=token value=1358616358 type=hidden input name=nextStep
value=upload type=hidden
script language=Javascript
document.forms[0].encoding='multipart/form-data';
/script
/td/tr
tr height=1%tdinput name=ok value=nbsp;nbsp;OKnbsp;nbsp;
onclick=javascript: disabled=1; doSubmit('ok'); type=button
nbsp;input name=cancel value=Cancel onclick=self.close();
type=button /td/tr/tablescript
language=javascriptself.focus()/scriptinput type=hidden
name=formAction
value=ws_ext?servlet=upload_file_project_attributesamp;fileAttr=CompletedDTPCaptionKitamp;project=30452amp;token=1358616358amp;random=6674
input type=hidden name=submittedBy value=
input type=hidden name=methodUsed value=GET
script language=javascript
function doSubmit(name) {
document.forms[0].action=document.forms[0].formAction.value;
document.forms[0].target='_self';
document.forms[0].submittedBy.value=name;
document.forms[0].submit();
}
/script
/form
/body
/html
0
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Fri, 08 Nov 2013 11:24:05 GMT
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
45
. script language=javascriptwindow.scrollTo(0, 1);/script
Walter
From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org,
Date: 03/02/2014 12:10
Subject:Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 10:47, walter.heesterm...@toyota-europe.com wrote:
Hi,
I have requested the trext format. In the meantime, how can I disable
the
'Chunked Transfer-Encoding' inside Tomcat server?
You can't.
Mark
Regards
Walter
From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org,
Date: 03/02/2014 11:15
Subject:Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 09:34, walter.heesterm...@toyota-europe.com wrote:
Hi,
We have some weird behaviopur with one of our applications using
apache-tomcat-6.0.37.
This is the report of the newtork engineer:
/The application (or app server - apache/coyote) is returning a
response
with Chunked Transfer-Encoding, but is sending the first chunks
before
giving the http headers (that defines the chunk-encoding).
That strikes me as pretty unlikely given the length of time 6.0.x has
been released and the lack of similar reports.
It may be possible if the application is doing something it shouldn't,
like holding on to a reference to a response object and re-using it
across multiple requests.
The result is that the client receives a response stating by the
definition on the chunk lenght (7a5), and as the header
Content-Encoding has not been received, that length definition is
interpreted as response characters.
Here is a dump of the communication between TARS Reverse Proxy and the
Back-end. (You
Re: Tomcat 7.0. Webdav returns 0x80070021
On 03/02/2014 10:43, Sampers, Ruud wrote: Tomcat 7.047. Default setup form web. Added an webapp with webdav enabled readonly = false; Windows 7: Mapped a drive to the specific folder: View content OK, put creating a new file/folder results in a dialog There is a long list of things that are broken in various versions of the Microsoft WebDAV client. You should try the WebdavFixFilter which identifies some of them and even fixes a few where it can. That said, I am sure there will be problems that that filter doesn't catch. I'll see if I have a Windows 7 client handy to test with and see if I can reproduce this. Mark Localhost logging: 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document.txt HTTP/1.1 207 850 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document%20(2).txt HTTP/1.1 207 864 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PROPFIND /webdav/dat1/New%20Text%20Document%20(3).txt HTTP/1.1 404 1011 127.0.0.1 - - [03/Feb/2014:11:40:34 +0100] PUT /webdav/dat1/New%20Text%20Document%20(3).txt HTTP/1.1 409 1001 Anyone familiar with this behavior, or known solutions. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backupManager - backup on all nodes and slowly
On 03/02/2014 11:31, Ja kub wrote: But time is not such a great problem for me. Time of execution was mentioned only in addition - there are 100 k requests. I am mainly interested in memory, and how BackupManager works. I hoped, that with BackupManager memory will increase on node which is queried and ONLY on one backup node, but here it is increasing on all 4 nodes in cluster. Should BackupManager be working as I write above, or do I understand it wrong ? Your understanding of the backup manager is not correct. See http://people.apache.org/~markt/presentations/2013-02-Apache-Tomcat-Clustering.pdf Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.0.1 (beta) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.1 (beta). Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8 is aligned with Java EE 7. In addition to supporting updated versions of the Java EE specifications, Tomcat 8 includes a number of improvements compared to Tomcat 7. The notable changes include: - Support for Java Servlet 3.1, JavaServer Pages 2.3, Java Unified Expression Language 3.0 and Java WebSocket 1.0. - The default connector implementation is now the Java non-blocking implementation (NIO) for both HTTP and AJP. - A new resources implementation that replaces Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories with a single, consistent approach for configuring additional web application resources. The new resources implementation can also be used to implement overlays (using a master WAR as the basis for multiple web applications that each have their own customizations). Apache Tomcat 8.0.1 includes numerous fixes for issues identified in RC10 as well as a number of other enhancements and changes. The notable changes since RC10 include: - Fix sendFile support for the NIO connector. - Move control of caching and linking options from the Context to the WebResourceRoot to enable them to by changed while the web application is running. - Add support for a dedicated listener for class loader binding and unbinding events. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html The purpose of this beta release is to give users an opportunity to test Tomcat 8 and to provide feedback to the Tomcat community. Although it is a beta release, it is expected to run stably and is being used in production at the ASF for the ASF's Jira instance. The beta status is primarily because the Tomcat developers feel more feedback is required before a stable release. It is also because 8.0.1 depends on a snapshot rather than a release build of Apache Commons DBCP2 and because there may be a small amount of further refactoring. Note: This version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie issue with Tomcat 7 - does not accept the character é
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other languages) (*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not include
é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated explicitly and
implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers, and it also does
not specifically indicate which character set should be used for HTTP Request/Response
header values. It refers for that to MIME (RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and lastly defined in RFC
6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can (regrettably still) only
consist of US-ASCII characters (not including é thus).
(I cannot find in the specs a way to quote a non-US-ASCII character either; that's
apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to encode the Cookie value
via e.g. Base64, if it were to potentially contain non US-ASCII characters).
The cookie name is a token, and the definition of token sends us back to
RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie names (as well as
values) can only consist of US-ASCII characters, and that é is thus not allowed (without
some form of encoding that would represent it as a sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I cannot imagine how it
can be nowadays that nobody has yet gotten around to proposing a HTTP 2.0 RFC where the
default character set would be Unicode, UTF-8 encoded, for everything excluding maybe
header names. But that's neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed rejects a Cookie header
containing any non-US-ASCII character (whether in the cookie name or value).
- That the error message could be improved (é is not a control character, it's just
invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie value before sending
it to the browser.
That's also because it may happen one day that even a browser which respects the specs to
the letter (one never knows), could reject a value like :
abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
(*) The question of whether Catalan is a language, or merely a northern dialect of
Valenciano, is left to the reader's appreciation ( ;-) ).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backupManager - backup on all nodes and slowly
Ok, thx, 2 questions: 1) If I will have only one very large session (about 100Mb), will memory increase only on one backup node, and on 2 other nodes in cluster memory will not increase ? 2) On 18080 node, on which all queries where asked memory increased not too much than 100Mb, and on each of other nodes memory also increased about 100 Mb. Is it not strange ? I would expect about 35-50 Mb of memory increase on each of 3 backup nodes. Now memory consumption is the same as with Delta Manager. On Mon, Feb 3, 2014 at 12:36 PM, Mark Thomas ma...@apache.org wrote: On 03/02/2014 11:31, Ja kub wrote: But time is not such a great problem for me. Time of execution was mentioned only in addition - there are 100 k requests. I am mainly interested in memory, and how BackupManager works. I hoped, that with BackupManager memory will increase on node which is queried and ONLY on one backup node, but here it is increasing on all 4 nodes in cluster. Should BackupManager be working as I write above, or do I understand it wrong ? Your understanding of the backup manager is not correct. See http://people.apache.org/~markt/presentations/2013-02-Apache-Tomcat-Clustering.pdf Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
On Feb 3, 2014, at 3:30 AM, Maor Yosef maoryo...@gmail.com wrote: Hi. 1. We are aware that 6.0.26 is old, but since there is a large operational impact, we wont upgrade the tomcat until we will know its definetly an issue in this specific version While I understand what you’re saying, I disagree. If you need to sell the change to management, you should take a look at the security problems that have been fixed since 6.0.26 and weigh the cost of upgrading versus a security breach or manually applying mitigations, if that’s even possible. http://tomcat.apache.org/security-6.html 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread” This is telling you that there’s not enough memory to allocate any more threads. 1.) Have you tried setting “-Xss”? This will set the thread stack size, i.e. how much memory each thread has available for its stack. Often times you don’t need nearly as much as the default allocated by the JVM, so you can lower it and get more threads out of the same available memory. Maybe try 256k or even lower. You’ll know you went too low if you see StackOverflowErrors. 2.) How many threads are being created / used? Perhaps you’re creating too many threads? You’ll probably want to do some monitoring and see how many the Tomcat is creating / using and how many your application is creating / using. Perhaps you’ve got a problem where too many threads are being created or where threads are being created and not properly cleaned up. Tools that could help here: jconsole / jvisualvm or thread dumps 3. Looking at the sessions manager, we see a lot of sessions with a negative TTL - meaning they werent expired, if I manually expire them then the sessions count decreases. This doesn’t sound related, although it’s hard to say. Might be helpful if you can include your configuration, minus comments. 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? What exactly do you mean here? You can control Tomcat’s thread usage with an Executor [1] or directly on the connector [2]. Dan [1] - http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html [2] - http://tomcat.apache.org/tomcat-6.0-doc/config/http.html Thanks, On Sun, Feb 2, 2014 at 7:38 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2014-02-02 Maor Yosef maoryo...@gmail.com: Hi, 1. 6.0.26 is old. We are facing issues where the sessions are not being expired and eventually causing a stack overflow. 2. Non-expiring sessions may cause OOM, but they cannot cause a stack overflow. What are your evidences? We see that at some point the sessions get pilled up and we need to manually expire those sessions through the manager application, or until we will restart tomcat but after a few hours / days, sessions will start to get stuck again 3. Increasing count of session does not mean that sessions do not expire. Your evidence = ? We see it in all the applications that are deployed on tomcat, including the manager application - this rules out (in my opinion) the possibility that its an issue with our application. 4. Sessions are expired by a background thread. If the thread is stuck somewhere (e.g. doing auto-deployment work) it will affect expiration of sessions. Your thread dump = ? By default there is one background thread that is shared by all container levels in Tomcat, but you can configure a separate one in each container (container = Context, Host or Engine). 5. Web bots that do not support cookies may generate multiple sessions. See CrawlerSessionManagerValve Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie issue with Tomcat 7 - does not accept the character é
André Warnier wrote:
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other
languages) (*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not
include é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated
explicitly and implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers,
and it also does not specifically indicate which character set should be
used for HTTP Request/Response header values. It refers for that to MIME
(RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and
lastly defined in RFC 6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can
(regrettably still) only consist of US-ASCII characters (not including
é thus).
(I cannot find in the specs a way to quote a non-US-ASCII character
either; that's apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to
encode the Cookie value via e.g. Base64, if it were to potentially
contain non US-ASCII characters).
The cookie name is a token, and the definition of token sends us
back to RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie
names (as well as values) can only consist of US-ASCII characters, and
that é is thus not allowed (without some form of encoding that would
represent it as a sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I
cannot imagine how it can be nowadays that nobody has yet gotten around
to proposing a HTTP 2.0 RFC where the default character set would be
Unicode, UTF-8 encoded, for everything excluding maybe header names.
But that's neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed
rejects a Cookie header containing any non-US-ASCII character (whether
in the cookie name or value).
- That the error message could be improved (é is not a control
character, it's just invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie
value before sending it to the browser.
That's also because it may happen one day that even a browser which
respects the specs to the letter (one never knows), could reject a value
like : abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
As an appendix, and triggered by another post to this list, here is another way of
encoding HTTP header values :
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
In this case, the cookie values are encoded using a MIME extension scheme which
indicates (between =? ? ?) prior to a string's value, the character set/encoding in which
the subsequent string is to be interpreted.
This is not explicitly mentioned in any of the above references, but as I recall, this is
part of another series of RFC's, maybe starting at this one :
http://tools.ietf.org/html/rfc2184
Now how this works out (also
Re: cookie issue with Tomcat 7 - does not accept the character é
On 03/02/2014 12:19, André Warnier wrote:
André Warnier wrote:
Christopher Schultz wrote:
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
Read https://wiki.apache.org/tomcat/Cookies
Look for the references to UTF-8. It isn't currently supported but it
will be.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0. Webdav returns 0x80070021
On 03/02/2014 11:32, Mark Thomas wrote: On 03/02/2014 10:43, Sampers, Ruud wrote: Tomcat 7.047. Default setup form web. Added an webapp with webdav enabled readonly = false; Windows 7: Mapped a drive to the specific folder: View content OK, put creating a new file/folder results in a dialog There is a long list of things that are broken in various versions of the Microsoft WebDAV client. You should try the WebdavFixFilter which identifies some of them and even fixes a few where it can. That said, I am sure there will be problems that that filter doesn't catch. I'll see if I have a Windows 7 client handy to test with and see if I can reproduce this. Looks like Windows 7 only likes connecting on port 80. Not much Tomcat can do about that. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
2014-02-03 Maor Yosef maoryo...@gmail.com: Hi. Please read the rules and do not top-post, as it is hard to follow. http://tomcat.apache.org/lists.html#tomcat-users 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? By setting a positive value for backgroundProcessorDelay attribute. http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html#Common_Attributes The rest was answered by Daniel. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 11:21, walter.heesterm...@toyota-europe.com wrote: If it can't be disabled, who is then generating the issue, can it be tomcat issue or issue application relatd, not using correct response? As per my original response, this is most likely an application issue. Can you reproduce this with a simple web application (ideally a single Servlet or JSP) that demonstrates the issue on a clean Tomcat installation? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
I can't reproduce it with simple web application, it happens in one of our applications, SDL WorldServer application which we bought for translations. Even there the issue is random. Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 13:43 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 11:21, walter.heesterm...@toyota-europe.com wrote: If it can't be disabled, who is then generating the issue, can it be tomcat issue or issue application relatd, not using correct response? As per my original response, this is most likely an application issue. Can you reproduce this with a simple web application (ideally a single Servlet or JSP) that demonstrates the issue on a clean Tomcat installation? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately.
Re: backupManager - backup on all nodes and slowly
On 03/02/2014 11:59, Ja kub wrote: Ok, thx, 2 questions: 1) If I will have only one very large session (about 100Mb), will memory increase only on one backup node, and on 2 other nodes in cluster memory will not increase ? You should see an increase on the primary and the backup node for that session. The proxy sessions on the other two nodes should be minimal since they just hold the session ID and the locations of the primary and backup copies. 2) On 18080 node, on which all queries where asked memory increased not too much than 100Mb, and on each of other nodes memory also increased about 100 Mb. Is it not strange ? I would expect about 35-50 Mb of memory increase on each of 3 backup nodes. Now memory consumption is the same as with Delta Manager. It depends a lot on what that memory is doing. You'd need to look very carefully with a profiler to be sure of what was going on. You can use the Manager app to see which sessions are on which nodes in what state. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
On 03/02/2014 12:46, walter.heesterm...@toyota-europe.com wrote: I can't reproduce it with simple web application, it happens in one of our applications, SDL WorldServer application which we bought for translations. Even there the issue is random. Do the affected requests pass through any filters? Do you have the source code for those filters? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
We don't have the source code Walter From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org, Date: 03/02/2014 13:50 Subject:Re: Tomcat and Chunked Transfer-Encoding On 03/02/2014 12:46, walter.heesterm...@toyota-europe.com wrote: I can't reproduce it with simple web application, it happens in one of our applications, SDL WorldServer application which we bought for translations. Even there the issue is random. Do the affected requests pass through any filters? Do you have the source code for those filters? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail may contain confidential information. If you are not an addressee or otherwise authorised to receive this message, you should not use, copy, disclose or take any action based on this e-mail. If you have received this e-mail in error, please inform the sender promptly and delete this message and any attachments immediately.
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
On Mon, Feb 3, 2014 at 2:10 PM, Daniel Mikusa dmik...@gopivotal.com wrote: On Feb 3, 2014, at 3:30 AM, Maor Yosef maoryo...@gmail.com wrote: Hi. 1. We are aware that 6.0.26 is old, but since there is a large operational impact, we wont upgrade the tomcat until we will know its definetly an issue in this specific version While I understand what you're saying, I disagree. If you need to sell the change to management, you should take a look at the security problems that have been fixed since 6.0.26 and weigh the cost of upgrading versus a security breach or manually applying mitigations, if that's even possible. http://tomcat.apache.org/security-6.html I agree that an upgrade is needed, but still before we will determine to which version to upgrade, we need to solve this issue 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread This is telling you that there's not enough memory to allocate any more threads. 1.) Have you tried setting -Xss? This will set the thread stack size, i.e. how much memory each thread has available for its stack. Often times you don't need nearly as much as the default allocated by the JVM, so you can lower it and get more threads out of the same available memory. Maybe try 256k or even lower. You'll know you went too low if you see StackOverflowErrors. 2.) How many threads are being created / used? Perhaps you're creating too many threads? You'll probably want to do some monitoring and see how many the Tomcat is creating / using and how many your application is creating / using. Perhaps you've got a problem where too many threads are being created or where threads are being created and not properly cleaned up. Tools that could help here: jconsole / jvisualvm or thread dumps The memory configuration doesn't seems to be the issue, as mentioned before we see a direct correlation between the amount of opened sessions (which can go as high as 100k+) even for a simple application that is just running a simple jsp file, which only prints back to the screen OK, we still see a large number of sessions for it (also after adding a web.xml with session expiration time = 1) 3. Looking at the sessions manager, we see a lot of sessions with a negative TTL - meaning they werent expired, if I manually expire them then the sessions count decreases. This doesn't sound related, although it's hard to say. Might be helpful if you can include your configuration, minus comments. 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? What exactly do you mean here? You can control Tomcat's thread usage with an Executor [1] or directly on the connector [2]. Dan [1] - http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html [2] - http://tomcat.apache.org/tomcat-6.0-doc/config/http.html Thanks, On Sun, Feb 2, 2014 at 7:38 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2014-02-02 Maor Yosef maoryo...@gmail.com: Hi, 1. 6.0.26 is old. We are facing issues where the sessions are not being expired and eventually causing a stack overflow. 2. Non-expiring sessions may cause OOM, but they cannot cause a stack overflow. What are your evidences? We see that at some point the sessions get pilled up and we need to manually expire those sessions through the manager application, or until we will restart tomcat but after a few hours / days, sessions will start to get stuck again 3. Increasing count of session does not mean that sessions do not expire. Your evidence = ? We see it in all the applications that are deployed on tomcat, including the manager application - this rules out (in my opinion) the possibility that its an issue with our application. 4. Sessions are expired by a background thread. If the thread is stuck somewhere (e.g. doing auto-deployment work) it will affect expiration of sessions. Your thread dump = ? By default there is one background thread that is shared by all container levels in Tomcat, but you can configure a separate one in each container (container = Context, Host or Engine). 5. Web bots that do not support cookies may generate multiple sessions. See CrawlerSessionManagerValve Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0. Webdav returns 0x80070021
Mark Thomas wrote: On 03/02/2014 11:32, Mark Thomas wrote: On 03/02/2014 10:43, Sampers, Ruud wrote: Tomcat 7.047. Default setup form web. Added an webapp with webdav enabled readonly = false; Windows 7: Mapped a drive to the specific folder: View content OK, put creating a new file/folder results in a dialog There is a long list of things that are broken in various versions of the Microsoft WebDAV client. You should try the WebdavFixFilter which identifies some of them and even fixes a few where it can. That said, I am sure there will be problems that that filter doesn't catch. I'll see if I have a Windows 7 client handy to test with and see if I can reproduce this. Looks like Windows 7 only likes connecting on port 80. Not much Tomcat can do about that. From memory of previous investigations, I think it is a bit more complicated : It wants either the connection to be https, or else it only accepts to be mapped to a root URL. In other words, something like : - map to https://server.company.com:443/somefolder/; is OK - map to http://server.company.com/somefolder/; is not OK - map to http://server.company.com/; is OK But, as you mentioned earlier, the list of inconsistencies and problems with the various Microsoft DAV client implementations is just about endless. We have resorted to using separate DAV clients instead (WebDrive e.g.). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
On Feb 3, 2014, at 9:00 AM, Maor Yosef maoryo...@gmail.com wrote: On Mon, Feb 3, 2014 at 2:10 PM, Daniel Mikusa dmik...@gopivotal.com wrote: On Feb 3, 2014, at 3:30 AM, Maor Yosef maoryo...@gmail.com wrote: Hi. 1. We are aware that 6.0.26 is old, but since there is a large operational impact, we wont upgrade the tomcat until we will know its definetly an issue in this specific version While I understand what you're saying, I disagree. If you need to sell the change to management, you should take a look at the security problems that have been fixed since 6.0.26 and weigh the cost of upgrading versus a security breach or manually applying mitigations, if that's even possible. http://tomcat.apache.org/security-6.html I agree that an upgrade is needed, but still before we will determine to which version to upgrade, we need to solve this issue 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread This is telling you that there's not enough memory to allocate any more threads. 1.) Have you tried setting -Xss? This will set the thread stack size, i.e. how much memory each thread has available for its stack. Often times you don't need nearly as much as the default allocated by the JVM, so you can lower it and get more threads out of the same available memory. Maybe try 256k or even lower. You'll know you went too low if you see StackOverflowErrors. 2.) How many threads are being created / used? Perhaps you're creating too many threads? You'll probably want to do some monitoring and see how many the Tomcat is creating / using and how many your application is creating / using. Perhaps you've got a problem where too many threads are being created or where threads are being created and not properly cleaned up. Tools that could help here: jconsole / jvisualvm or thread dumps The memory configuration doesn't seems to be the issue, I would beg to differ. It’s certainly one issue. You seem to have multiple. As I said previously, I don’t think your OOME is related to your session problem. At least it doesn’t seem to be based on the information you’ve given to date. as mentioned before we see a direct correlation between the amount of opened sessions (which can go as high as 100k+) even for a simple application that is just running a simple jsp file, which only prints back to the screen OK, we still see a large number of sessions for it (also after adding a web.xml with session expiration time = 1) Here’s what I’d suggest. 1.) In a test environment, install Tomcat 6.0.39. It’s the latest. 2.) Deploy your “simple application”, if it’s really as simple as you say it shouldn’t be a problem to install. 3.) See if you can replicate the problem. If so then report your findings here, just include a test app your steps to reproduce. If you’re unable to reproduce the issue, then consider upgrading or compare your configuration’s to see if your current config is doing something wrong. Also, please realize that a JSP page, even one that simply prints out “OK” will create a session. This is by design and if you don’t want it to create a session you need to explicitly indicate that in your JSP. Ex: %@ page session=false % This is important in scenarios where you’re doing load testing and using custom HTTP clients, because these client’s may not be handling sessions correctly and thus end up creating a new session every time they access the page. Another way to handle misbehaving clients is, what Konstantin mentioned in his earlier message about web bots, the CrawlerSessionManagerValve. 3. Looking at the sessions manager, we see a lot of sessions with a negative TTL - meaning they werent expired, if I manually expire them then the sessions count decreases. This doesn't sound related, although it's hard to say. Might be helpful if you can include your configuration, minus comments. Are you going to provide your configuration? There’s only so much we can tell you without knowing how you have your environment configured. Dan 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? What exactly do you mean here? You can control Tomcat's thread usage with an Executor [1] or directly on the connector [2]. Dan [1] - http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html [2] - http://tomcat.apache.org/tomcat-6.0-doc/config/http.html Thanks, On Sun, Feb 2, 2014 at 7:38 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2014-02-02 Maor Yosef maoryo...@gmail.com: Hi, 1. 6.0.26 is old. We are facing issues where the sessions are not being expired and eventually causing a stack overflow. 2. Non-expiring sessions may cause OOM, but
Re: Tomcat and Chunked Transfer-Encoding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Walter,
On 2/3/14, 6:31 AM, walter.heesterm...@toyota-europe.com wrote:
Here the text format of the traffic
GET
/ws/ws_ext?servlet=upload_file_project_attributesfileAttr=CompletedDTPCaptionKitproject=30452token=1358616358random=0.5308450920567584
HTTP/1.1 Host: td3worldserverlb.toyota-europe.com Accept:
text/html, application/xhtml+xml, */* Accept-Language: nl-NL
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1;
WOW64; Trident/6.0) Accept-Encoding: gzip, deflate DNT: 1 Cookie:
ACE_COOKIE=R660302447; TD3World=R760446058 SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?= SM_SDOMAIN:
=?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?= X-Forwarded-For: 77.60.99.113
X-Forwarded-Host: mytechdoc.toyota-europe.com X-Forwarded-Server:
mytechdoc.toyota-europe.com Connection: Keep-Alive
7a5
Just curious... does the response end up being 1957 bytes? I'm not
going to count them (nor can I... I don't know what newline style was
in use when the data was sent).
html head titleIdiom WorldServer - File Upload Page/title
link rel='stylesheet' href='style.css' type='text/css' script
language=JavaScript src='general.js'/script script
language=JavaScript src='ips.js'/script script
language=JavaScript
src='ws_ext?servlet=include_proxyfileName=ips.jstoken=1358616358'/script
script
language=JavaScriptlocation.href=location.href+'customopenertoken='+
getOpenerToken();/script /head
body onload=requestFocus('uploadedFile') form
style=width:100%; height: 100% method=post table width=100%
height=100% cellpadding=5tr height=1%td
class=popup_dialog_headerFile Upload/td/trtr
height=100%td valign=top iClick on Browse button to browse
and select the file to upload. /ipinput name=uploadedFile
value= type=file input name=fileAttr
value=CompletedDTPCaptionKit type=hidden input name=token
value=1358616358 type=hidden input name=nextStep
value=upload type=hidden script language=Javascript
document.forms[0].encoding='multipart/form-data'; /script
/td/tr tr height=1%tdinput name=ok
value=nbsp;nbsp;OKnbsp;nbsp; onclick=javascript: disabled=1;
doSubmit('ok'); type=button
nbsp;input name=cancel value=Cancel
onclick=self.close();
type=button /td/tr/tablescript
language=javascriptself.focus()/scriptinput type=hidden
name=formAction
value=ws_ext?servlet=upload_file_project_attributesamp;fileAttr=CompletedDTPCaptionKitamp;project=30452amp;token=1358616358amp;random=6674
input type=hidden name=submittedBy value=
input type=hidden name=methodUsed value=GET script
language=javascript function doSubmit(name) {
document.forms[0].action=document.forms[0].formAction.value;
document.forms[0].target='_self';
document.forms[0].submittedBy.value=name;
document.forms[0].submit(); } /script /form /body /html
0
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Transfer-Encoding:
chunked Date: Fri, 08 Nov 2013 11:24:05 GMT
45 . script language=javascriptwindow.scrollTo(0,
1);/script 45 . script
language=javascriptwindow.scrollTo(0, 1);/script 45 .
script language=javascriptwindow.scrollTo(0,
1);/script 45 . script
language=javascriptwindow.scrollTo(0, 1);/script 45 .
script language=javascriptwindow.scrollTo(0,
1);/script 45 . script
language=javascriptwindow.scrollTo(0, 1);/script 45 .
script language=javascriptwindow.scrollTo(0,
1);/script 45 . script
language=javascriptwindow.scrollTo(0, 1);/script 45 .
script language=javascriptwindow.scrollTo(0,
1);/script 45 . script
language=javascriptwindow.scrollTo(0, 1);/script
That's odd. If you really are getting chunk #0 before the initial
headers, then what is chunk #1 supposed to include? Chunk #0 looks
like it's got a completely self-contained HTML document. Where would
the other chunk go into it?
What Connector are you using? Are you fronting the application
server with a web server like httpd, etc.? If so, how do you connect
the two of them (e.g. mod_jk, etc.)?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS79hlAAoJEBzwKT+lPKRY+A4P/3jgV6eqK2ccdL4wlhJcld94
h8mlyDXoyUDfuggi48SYNGAuqvh9QOqYz8FvEIZhc41iaghziW7BkrhVvh0u7vbv
wv7MEyYYTh2jjXvrzkKp8UIttQa8W5nvInzCG3ykIB82LFH5RwnTnezGBAtPtOp4
VVJxS+chL0XiRI/JqYm0bCOpWiKz5Xb+IV5TwrE5xcBYGB5Fi9waTrPZ6Ugm4Pdc
2e9RkcOVBefQDXDk2JeD+34B2um4J2e0xsS+irL9dSPBhXMhl8ai141/dkeRkJiF
vJ5/ET9umWoCjEb468K8hz/xHsiQ9mAxaBeMfu75eHhf/UZgcpdH933gXnJbJJGT
yCVYPuTWas/eLL9EiF0tBzrFthwgzFwiheSEk0ghi6shp3U8/IEk4AlVaA5lG09s
4f3qhSmwqFW+ITUkAOeGZAAlXLB6N8lH3D7o46KYq+Oqe9+2ogqXkTQq8R9gNQgF
CS3jaoRymWayNnGGGt+v/b2mHzc0Tt07l0i6QayhPmchWtM1W7wIuBIM3R6iyvod
8ZyOL4bAWfqGzgsfTV9gXS6gvA12Jii6fNqd72l5gPSf6GmCr5VPyWsCeAiu0CyW
ZBLN/dCyAxdLuqNF3Me8c1vWOi/VxQ6TsgI8k/1EmWTQUxOeiajaY5Aup0jPjjpe
Re: Tomcat 7.0. Webdav returns 0x80070021
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/3/14, 7:39 AM, Mark Thomas wrote: On 03/02/2014 11:32, Mark Thomas wrote: On 03/02/2014 10:43, Sampers, Ruud wrote: Tomcat 7.047. Default setup form web. Added an webapp with webdav enabled readonly = false; Windows 7: Mapped a drive to the specific folder: View content OK, put creating a new file/folder results in a dialog There is a long list of things that are broken in various versions of the Microsoft WebDAV client. You should try the WebdavFixFilter which identifies some of them and even fixes a few where it can. That said, I am sure there will be problems that that filter doesn't catch. I'll see if I have a Windows 7 client handy to test with and see if I can reproduce this. Looks like Windows 7 only likes connecting on port 80. Not much Tomcat can do about that. Microsoft really broke their WebDAV client over time, and I've had to deal with a number of those issues until I had to finally give up with Windows 7 and use WebDrive (which has worked really well for us, BTW). I didn't know about any port-80 issues, though: we do everything over HTTPS and I do know that even over HTTPS, it requires that any authentication be done using HTTP-Digest -- you can't use HTTP-Basic. :( Ruud, can you try using another DAV client such as WebDrive (there is a time-limited trial you can download and install at no cost)? That will tell you whether your Tomcat configuration is correct or if the problem is with Microsoft's brain-dead WebDAV client. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS79ngAAoJEBzwKT+lPKRYq74P/2h/dGGFoVJdi7UKZKctLUs1 638s3p96sN71M/TR82H7ckU9hlweoDAkB9oKwuttQRKkkvVKY1TaueYQ6ODth6+L RhD1D5YmkgpE9MaHWsEsEGd6L7gzndrEbPurLERIH89sbxBXxKC17fL3ASl+ojt2 8CgPjC9pLgH15FcAns5f8Ai+P33Iyzjti+v4ioLGOKrI1tDWD6xpY8wGpkFx57A8 BS4yDSOCjZvj/SDBqmADUGTaGuQnottC1YZ4hUKWG4SspQ4JJyO/2YgMXsrw7Cys vj+rptgBjos1ZHLIaANSPdYN+Qj4hWgszrYl1aAZ8hTNtmApOZ/D4nsk65fC7emm SiZz9jCEcRfmFZstL3l8RGCR/B8Ux/M3wdwyR0Sf/uuXBrh66iJWBf5Je4kVsBsW APgxXqc3aURn4LCqceaDMJGV8xAfYziCBwFEV3F2ZlmWZMTGc2thU6W53G3V9G/J uBCwjO38pYyo4alDCHmTZkotdnswiPkWX/H6ZsMQKfuw+Vmb+GMypCeTbcvB2myR 78AqkJNIVfHAT+pJ5Qu6AeXvsO1m46VcxkmRDEXsvGTHBP+OKA4IcpDyt3f5yd39 WrPYXHZ03QL2hds1ztlr7myquzfFZ1XWtc9vz2ImhS/y3C/e2XnSppaQufrKSlac Emg9Cu4QomqCaWUQKnX4 =l6O0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 2/3/14, 7:10 AM, Daniel Mikusa wrote: On Feb 3, 2014, at 3:30 AM, Maor Yosef maoryo...@gmail.com wrote: Hi. 1. We are aware that 6.0.26 is old, but since there is a large operational impact, we wont upgrade the tomcat until we will know its definetly an issue in this specific version While I understand what you’re saying, I disagree. If you need to sell the change to management, you should take a look at the security problems that have been fixed since 6.0.26 and weigh the cost of upgrading versus a security breach or manually applying mitigations, if that’s even possible. http://tomcat.apache.org/security-6.html +1 2. You are right, it was my mistake, it causes OOM and not stack overflow, when we see high sessions count we get exceptions saying unable to create new native thread” This is telling you that there’s not enough memory to allocate any more threads. 1.) Have you tried setting “-Xss”? This will set the thread stack size, i.e. how much memory each thread has available for its stack. Often times you don’t need nearly as much as the default allocated by the JVM, so you can lower it and get more threads out of the same available memory. Maybe try 256k or even lower. You’ll know you went too low if you see StackOverflowErrors. 2.) How many threads are being created / used? Perhaps you’re creating too many threads? You’ll probably want to do some monitoring and see how many the Tomcat is creating / using and how many your application is creating / using. Perhaps you’ve got a problem where too many threads are being created or where threads are being created and not properly cleaned up. Tools that could help here: jconsole / jvisualvm or thread dumps I'd be interested in knowing why threads are being created at all. Thread dumps will reveal a lot of good information. 3. Looking at the sessions manager, we see a lot of sessions with a negative TTL - meaning they werent expired, if I manually expire them then the sessions count decreases. This doesn’t sound related, although it’s hard to say. Might be helpful if you can include your configuration, minus comments. 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? If your background thread is becoming stuck, you should fix *that* instead of trying to work-around it. Thread dump(s)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS7+VNAAoJEBzwKT+lPKRYcjkP/2A0gQ3HnJNOA2724kxHiYO/ q4ZLnqJUAnepPttDYu4eL8/sehnmLm1kNQ0q/vby+5LLXLeU3QldmJsZSHwDft7M +sph2hXy0Ed6a/3sS4nYEHLWYcIs9rEi13EkMTgvewE7jEp4QldTisfHi4I3XgDq ZlraHHQjvPgbYFwzQxmwg2F7+ag69GqR52q9zECC97tXctTPQHxd8hJ40298y40w 2HIyDV6l9EuPVkan1/g7xuWxRbWoAiwhawkiGA606r1IhtO7cB7C6ulAyDyoLKqj NEe1EHfVeDvmiavw7evIcknTVyK1hcuQC0NPV5bSMEQnQf6ZTWw67FQfosQUmqA2 L+kYtPKDzsnF9slUfgI7YokEjzApZx/dElsZUdgatIvb5yz8IFCXKaiFxkcHGffx TzHMe6EAiDZglM5fMQIPmvuS5p5/iaJ5mMTZzamcOZ2VOD1/RDtqQm5MLljd4M/0 cVpGb/xEEZLGoj8mnXTfQq+NFYbjkCA3PcglvoBi4VtgOS7pBykccEFEv+1HavHC h4ROzGJ8u7uHhGbUx2WbxHfkTtk6HGLon1bIyQkP1vraAdsOClAfiEto/C+bv9jw y5iLOfEEHlZTPCTv6lbDtYmTBaOO1r/3LQ12kc3eZfzjQaOuGUo7jwYc4A0yTDDJ 8V4q1aiF7dn26chh/BsS =R+5r -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.26 on Windows server - sessions are not expired
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 2/3/14, 7:40 AM, Konstantin Kolinko wrote: 2014-02-03 Maor Yosef maoryo...@gmail.com: Hi. Please read the rules and do not top-post, as it is hard to follow. http://tomcat.apache.org/lists.html#tomcat-users 4. Can you point me to an article on how to configure different background thread for each container? is it configured in tomcat or should be implemented in the application? By setting a positive value for backgroundProcessorDelay attribute. http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html#Common_Attributes The rest was answered by Daniel. I think taking any action before posting some thread dumps would be a mistake. I would be willing to bet that the background thread is getting stuck on something application-specific. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS7+X0AAoJEBzwKT+lPKRYRcEP/iy6lAankZZn3YqI6TKlTNbj 23XvQPdDalmxxcmLXMVh+2uCG5Pnsu8S4MtaJ8nSc5pKQctr7HmF7rdm2k0nCRLj 9Dvs2XtJWYDs+pCluxBBGC5egMafJjHo2Ivl2NHiVLVFNhEoOUVCD0mbth9nIoQv Uz1lZt/DENqZnGEUmu90w9vL7alJCceDmDEiet/Fb9r0yQXcXDmBktwOJdQjvNOB pOSuVlK+zO6axusNxOcIW47GdzFKl8USb5AJG9B6zw+KPaC6k5zam1k1NEegt9Mn d3O2zeUHEIaeO4IRemxRmPMW6haYDawW7sKUEWABVVBo1tgn0o0k1VvBNDLsO4xl nwQ617+D9xFgLWtJKyFWaLI9aT12QxA0VmBwouwyjnsN7XeU2VkFJPfQL+CUVfF/ X8MO06QQtGnfjFcvzM2QKUw24iF0Tc+vra1B8SEKVuRmX0QNvyze03lHhIsSsOql OYIW79uMMm6y8JUI3oidCdNHivHp264Ay49WDuHPZkgelIe3z1CKhj51LwfuccXc TgaDu6uCDoe2SLepRh1dZowF2v7OicLhUCxmn9loMA+f8ZeIV1edo+e/sXo/sCN6 1y9QYTKotE+zY91zM83zlstBw5E6FLEIURugOtimB9LlykSm+GafKMtr5Z91P2aU FFIcO6tw270I1jO+FQ9Y =M2Na -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and Chunked Transfer-Encoding
2014-02-03 Mark Thomas ma...@apache.org: On 03/02/2014 12:46, walter.heesterm...@toyota-europe.com wrote: I can't reproduce it with simple web application, it happens in one of our applications, SDL WorldServer application which we bought for translations. Even there the issue is random. 1. When response mixups happen, the first thing I would recommend is to set the following system property (you can add it to catalina.properties file): apache.catalina.connector.RECYCLE_FACADES=true Documentation: http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html#Security That will make your configuration more secure (at price of some performance) and will raise the chances that meddling with requests/response objects outside of their lifecycle would not go unnoticed. Then look for any odd messages in the log files. E.g. attempts to write to a closed stream, or an IllegalStateException, etc A known culprit is javax.imageio.ImageIO API http://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues So far it looks like an application issue, as Mark mentioned. 2. The convention on this mailing list is to do not top-post. http://tomcat.apache.org/lists.html#tomcat-users - 6. 3. What connector implementation are you using? HTTP/AJP? BIO/NIO/APR? I guess that you use HTTP and are behind an HTTP proxy. 4. Do you use any Asynchronous IO, Comet, WebSockets (e.g. via Atmosphere framework)? 5. In your traffic snippet, does that HTML response match the request, or a previous request? What generates those scrollTo script fragments? 6. Note that you can configure AccessLogValve to log your thread name (%I), http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0. Webdav Returns 0x80070021
LS, Native apache WebDAV implementation is unable to reroute the root directory to another location. The error returned was induced by experimenting with aliases in different directories outside the tomcat context, the logging revealed that on that specific url (via the alias) the webdav protocol is not available. After several experiments conducted with paths, docBase and aliases I came to the conclusion that the only thing that was working is webdav enabled in the ROOT, without having the possibility to put your content outside the webdav folder. Windows 7 (with my test cases) was not the issue, I also tried cyberduck webdav (great tool btw) gave the same responses. What worked for my is the: servlet-class net.sf.webdav.WebdavServlet /servlet-class Implementation 2 JARs put in the lib directory: WEB-INF +\LIB + jcl-over-slf4j-1.7.5.jar + slf4j-api-1.7.5.jar + webdav-servlet-2.0.1.jar Plus the default webdav servlet descriptor in the web.inf , rootpath put c:/tmp. Worked out of the box. From this I mapped drives from windows 7 and cyberduck and it al worked great. Basic crud like you would expect. Happy coding! Ruud Sampers. This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.
Re: Tomcat 5 Repository
On Wed, Jan 29, 2014 at 2:59 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: At least you've got the right mailing list this time. No idea where you were looking, but the 5.0 and 5.5 are pretty obvious when you look in the places linked to from the Tomcat home page: http://archive.apache.org/dist/tomcat/ http://svn.apache.org/repos/asf/tomcat/archive/ 2014-02-03 Pavneet singh Kochhar kochha...@gmail.com: Thanks for the help Chuck! 1. Follow the rules http://tomcat.apache.org/lists.html#tomcat-users - 6. Do not top-post. I checked the svn repository but coudn't really figure out how to get the commit logs which shows the files changed for Tomcat5. The commits show something like r588813 | markt | 2007-10-27 08:11:17 +0800 (Sat, 27 Oct 2007) | 1 line archive prep r588811 | markt | 2007-10-27 08:10:25 +0800 (Sat, 27 Oct 2007) | 1 line Create folder for 5.0.x archive which I believe are related to adding files to archive etc. However, I require the files changed during commits. 2. What are you trying to do and why? What is your goal? 3. What tools are you using? Do you know how to use those tools? 4. Tomcat 5.5 and earlier consist of several components (build, connectors, container, jasper, servletapi). Each of those was a separate project. Each of those had its own trunk/tags/branches structure Each of those has its own svn history. 5. Source code for older versions of Tomcat was migrated from CVS. CVS does not save history when files are renamed or copied. If you are looking for an old change, you may have to look for Tomcat 4 or earlier sources for the same-named file. 6. All commit e-mails can be found in mailing list archives. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie issue with Tomcat 7 - does not accept the character é
2014-02-03 André Warnier a...@ice-sa.com:
André Warnier wrote:
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other languages)
(*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not
include é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated
explicitly and implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers,
and it also does not specifically indicate which character set should be
used for HTTP Request/Response header values. It refers for that to MIME
(RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and
lastly defined in RFC 6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can
(regrettably still) only consist of US-ASCII characters (not including é
thus).
(I cannot find in the specs a way to quote a non-US-ASCII character
either; that's apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to encode
the Cookie value via e.g. Base64, if it were to potentially contain non
US-ASCII characters).
The cookie name is a token, and the definition of token sends us back
to RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie names
(as well as values) can only consist of US-ASCII characters, and that é is
thus not allowed (without some form of encoding that would represent it as a
sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I
cannot imagine how it can be nowadays that nobody has yet gotten around to
proposing a HTTP 2.0 RFC where the default character set would be Unicode,
UTF-8 encoded, for everything excluding maybe header names. But that's
neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed rejects
a Cookie header containing any non-US-ASCII character (whether in the cookie
name or value).
- That the error message could be improved (é is not a control
character, it's just invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie
value before sending it to the browser.
That's also because it may happen one day that even a browser which
respects the specs to the letter (one never knows), could reject a value
like : abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
As an appendix, and triggered by another post to this list, here is another
way of encoding HTTP header values :
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
In this case, the cookie values are encoded using a MIME extension scheme
which indicates (between =? ? ?) prior to a string's value, the character
set/encoding in which the subsequent string is to be interpreted.
This is not explicitly mentioned in any of the above references, but as I
recall, this is part of another series of RFC's, maybe
Re: application loggers not visible in jconsole
2014-01-31 Ja kub jjaku...@gmail.com:
changing logging level in logging properties works fine, but my custom
logger is not visible in jconsole under java.util.logging - loggerNames, I
can't change logging level dynamically by jconsole
I add into logging properties
test.logging.LoggingTest .level = FINE
and it successfully changes logs appearing in log file.
below is class used for logging
public class LoggingTest {
Logger logger = Logger.getLogger(LoggingTest .class.getName());
public LoggingTest () {
}
public void testLogging() {
logger.severe(test - ERROR);
logger.warning(test - WARNING);
logger.info(test - INFO);
logger.fine(test - FINE);
}
}
with setLogging level I get Illegal argument exception, logger doesn't
exist,
I don't see my logger in jconsole either.
Under java.util.logging - loggerNames I see only:
sun.rmi.transport.tcp
sun.management
javax.management.timer
sun.rmi.client.ref
javax.management.mlet
(...)
Management of loggers an exposing them via JMX is all done by JRE.
Tomcat has no say in that.
My guess would be that no instance of that logger class exists at that moment,
either because
a) An instance of LoggingTest class has not been created yet,
b) All instances of LoggingTest class have been garbage-collected.
All that depends on how you use your LoggingTest class.
This is just guess. The actual behaviour is provided by your JRE.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 / Java 7
Hello, I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL 5. Used the alternatives command to make the Java 7 as Java version. Now in my custom startup script if I define JAVA_HOME as JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( the previous version) and gives this message INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.45 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib 64:/lib64:/lib:/usr/lib I modified the JAVA_HOME to JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat starts and gives the message as INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib I believe it is not recognizing the correct Java version which is 1.7. Am I missing anything ? Thank you, -Ragini
Re: cookie issue with Tomcat 7 - does not accept the character é
Konstantin Kolinko wrote:
2014-02-03 André Warnier a...@ice-sa.com:
André Warnier wrote:
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other languages)
(*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not
include é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated
explicitly and implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers,
and it also does not specifically indicate which character set should be
used for HTTP Request/Response header values. It refers for that to MIME
(RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and
lastly defined in RFC 6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can
(regrettably still) only consist of US-ASCII characters (not including é
thus).
(I cannot find in the specs a way to quote a non-US-ASCII character
either; that's apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to encode
the Cookie value via e.g. Base64, if it were to potentially contain non
US-ASCII characters).
The cookie name is a token, and the definition of token sends us back
to RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie names
(as well as values) can only consist of US-ASCII characters, and that é is
thus not allowed (without some form of encoding that would represent it as a
sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I
cannot imagine how it can be nowadays that nobody has yet gotten around to
proposing a HTTP 2.0 RFC where the default character set would be Unicode,
UTF-8 encoded, for everything excluding maybe header names. But that's
neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed rejects
a Cookie header containing any non-US-ASCII character (whether in the cookie
name or value).
- That the error message could be improved (é is not a control
character, it's just invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie
value before sending it to the browser.
That's also because it may happen one day that even a browser which
respects the specs to the letter (one never knows), could reject a value
like : abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
As an appendix, and triggered by another post to this list, here is another
way of encoding HTTP header values :
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
In this case, the cookie values are encoded using a MIME extension scheme
which indicates (between =? ? ?) prior to a string's value, the character
set/encoding in which the subsequent string is to be interpreted.
This is not explicitly mentioned in any of the above references, but as I
recall, this is part of another series of RFC's, maybe starting at this one
:
http://tools.ietf.org/html/rfc2184
Now
Re: Tomcat 7 / Java 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ragini, On 2/3/14, 4:19 PM, Singh, Ragini wrote: I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL 5. Used the alternatives command to make the Java 7 as Java version. Now in my custom startup script if I define JAVA_HOME as JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( the previous version) and gives this message INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.45 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib 64:/lib64:/lib:/usr/lib I modified the JAVA_HOME to JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat starts and gives the message as INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib I believe it is not recognizing the correct Java version which is 1.7. Am I missing anything ? Have you installed tcnative? Installing tcnative is a prerequisite for using tcnative. Note that the above is an INFO message and not an error in any way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS8A0eAAoJEBzwKT+lPKRYss8P/05QCOEVNmHlbjrvyZplv2yI vLb9GL+5YhzNMawHoAKOeGzs3Pjkoux0+zbV5MNrvOZKhoM9r299eaoJTD9LVNbw Udz/Ip9TYmdPmP5OczO8D9+FNQX2pfzqSVMABMlLvi0/scC3EyV7/+PAZUEc/lYv K1Xm4mXiQpxCBBeS1v7D27WLzQGuIj4hj76aEwSf1tsw0GwMT6YKGioCjtSdBSeQ hVRmVI4CcqYwVrCNDXEF9El1ZO4QDN0l4FouApJd7/mlwTT6qRE9uTP9RUFmCGKh GT7yvP+rTnJ95A+c1jUe+FNRQDbiBAK+WMmqeNUL0GF/NVbGsL/DNykt1wrT1kR/ XgMsPWS/jFCeqpEpBBucKTrJalhNFiFltI1BLa0Lpc7eKtkWHbaDhFiSff/Q+Vf5 /ONLXsCmOSdDbzub7YH8CLlfWdykLJH++MuH1LPzy3dEkiCSFtwdAcmCo1fykH38 EtT0+Go0LNWoMKSQZYPOT3O5b71e3UgoKw8p9NWRpLNtsIVRFFsZZMomgBiVldQ1 H26Ng6rIK2XP+Aieq5V2VdraAByPkGQcKjGUexykPKZ4fewuCmKpQ+gKplxDyxFx uP/VcRp0jywUv/4kHjMBZG+eOFPySZ09i6QkZB80cIcoRIcfseTiBh0LqchclKyA VVbHk5QH86nuIKTo9zYF =JVDD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 / Java 7
Christopher, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ragini, On 2/3/14, 4:19 PM, Singh, Ragini wrote: I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle Java Runtime Environment on RHEL 5. Used the alternatives command to make the Java 7 as Java version. Now in my custom startup script if I define JAVA_HOME as JAVA_HOME=/usr/lib/jvm/java tomcat 7 recognizes the java as 1.6 ( the previous version) and gives this message INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.45 .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib 64:/lib64:/lib:/usr/lib I modified the JAVA_HOME to JAVA_HOME=/usr/lib/jvm/jre-1.7.0-oracle.x86_64. Now tomcat starts and gives the message as INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib I believe it is not recognizing the correct Java version which is 1.7. Am I missing anything ? Have you installed tcnative? Installing tcnative is a prerequisite for using tcnative. Note that the above is an INFO message and not an error in any way. I believe that the OP was wondering about the apparent discrepancy between his setting of the JAVA_HOME environment variable, and then what Tomcat prints as a java.library.path in the log messages. (And I do not know if there is actually here a real discrepancy; just that the OP mentions there might be one). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie issue with Tomcat 7 - does not accept the character é
2014-02-04 André Warnier a...@ice-sa.com:
Konstantin Kolinko wrote:
2014-02-03 André Warnier a...@ice-sa.com:
André Warnier wrote:
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other
languages)
(*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not
include é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated
explicitly and implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers,
and it also does not specifically indicate which character set should be
used for HTTP Request/Response header values. It refers for that to MIME
(RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and
lastly defined in RFC 6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can
(regrettably still) only consist of US-ASCII characters (not including
é
thus).
(I cannot find in the specs a way to quote a non-US-ASCII character
either; that's apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to
encode
the Cookie value via e.g. Base64, if it were to potentially contain non
US-ASCII characters).
The cookie name is a token, and the definition of token sends us
back
to RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie
names
(as well as values) can only consist of US-ASCII characters, and that
é is
thus not allowed (without some form of encoding that would represent it
as a
sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I
cannot imagine how it can be nowadays that nobody has yet gotten around
to
proposing a HTTP 2.0 RFC where the default character set would be
Unicode,
UTF-8 encoded, for everything excluding maybe header names. But that's
neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed
rejects
a Cookie header containing any non-US-ASCII character (whether in the
cookie
name or value).
- That the error message could be improved (é is not a control
character, it's just invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie
value before sending it to the browser.
That's also because it may happen one day that even a browser which
respects the specs to the letter (one never knows), could reject a value
like : abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
As an appendix, and triggered by another post to this list, here is
another
way of encoding HTTP header values :
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
In this case, the cookie values are encoded using a MIME extension
scheme
which indicates (between =? ? ?) prior to a string's value, the character
set/encoding in which the subsequent string is to be interpreted.
This is not explicitly mentioned in any of the
Re: Work temp queries-tomcat 6
Two corrections to what Chris wrote 2014-01-30 Christopher Schultz ch...@christopherschultz.net: On 1/30/14, 12:53 PM, vicky007aggar...@yahoo.co.in wrote: how work temp is being used by a Tomcat ?? The temp dir is required by the servlet spec. I don't believe Tomcat uses it for anything. The work directory is used to cache resources from WAR files, to compile .jsp files into .java and ultimately .class files, etc. The work directory is created automatically. The temp directory is not created automatically (to my surprise). The temp directory is just the value that is configured by default for java.io.tmpdir system property by Tomcat startup scripts. Tomcat code itself does not use this directory, but 3rd party libraries or JRE may use it. If temp directory does not exist, the following is logged: ... SEVERE [main] org.apache.catalina.startup.Catalina.initDirs Cannot find specified temporary folder at catalina.base path redacted...\temp The temp dir is required by the servlet spec. That is a different one. The temporary directory per servlet spec that is ServletContext.getAttribute(ServletContext.TEMPDIR) is different for each web application. In Tomcat those are at work/Engine name/Host name/webapp name Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie issue with Tomcat 7 - does not accept the character é
Konstantin Kolinko wrote:
2014-02-04 André Warnier a...@ice-sa.com:
Konstantin Kolinko wrote:
2014-02-03 André Warnier a...@ice-sa.com:
André Warnier wrote:
Chris,
a note :
Christopher Schultz wrote:
...
Without quoting, unquoted Cookie names and values may be any US-ASCII
character from 0x32 - 0x7e except for any of (( | ) | | |
@ | , | ; | : | \ | | / | [ | ] | ? | = | {
| } | SP | HT). None of the characters above are within that range,
so the cookie value must be quoted. (It looks to me like Cookie names
must always be in US-ASCII... I didn't think that was the case but I'm
not motivated to track-down every word of the spec looking for
justification).
What is the character encoding of the request? What client are you
using? Who created the cookie in the first place?
I did the tracking down of the (tortuous) specs, and come to this :
1) the ISO-8859-1 character set includes é (Catalan and other
languages)
(*)
2) the US-ASCII character set is a subset of ISO-8859-1, and does not
include é.
3) The default character set for HTTP 1.1 is ISO-8859-1, as stated
explicitly and implicitly in various places in RFC 2616 [1].
However, RFC 2616 does not define the Cookie nor Set-Cookie headers,
and it also does not specifically indicate which character set should be
used for HTTP Request/Response header values. It refers for that to MIME
(RFC 822), which talks only about US-ASCII.
2) The Cookie and Set-Cookie headers seem to be subsequently and
lastly defined in RFC 6265 [2].
In section 4.1.1 [3], the syntax of these headers is defined, as :
cookie-pair = cookie-name = cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = token, defined in [RFC2616], Section 2.2
Thus, it seems that you are right, and that a cookie *value* can
(regrettably still) only consist of US-ASCII characters (not including
é
thus).
(I cannot find in the specs a way to quote a non-US-ASCII character
either; that's apparently only allowed in parts defined as comments)
(It is stated somewhere else in RFC 6265 that it is recommended to
encode
the Cookie value via e.g. Base64, if it were to potentially contain non
US-ASCII characters).
The cookie name is a token, and the definition of token sends us
back
to RFC2616.
In 2.2 Basic Rules, RFC2616 states :
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
...
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
So, this all would tend to show that you are right, and that Cookie
names
(as well as values) can only consist of US-ASCII characters, and that
é is
thus not allowed (without some form of encoding that would represent it
as a
sequence of US-ASCII characters).
Which, in my personal opinion is a lasting p-i-t-a and shame. And I
cannot imagine how it can be nowadays that nobody has yet gotten around
to
proposing a HTTP 2.0 RFC where the default character set would be
Unicode,
UTF-8 encoded, for everything excluding maybe header names. But that's
neither here nor there.
To get back to the original OP's question thus, it seems to me that
- Tomcat 7.x would not be in violation of the specs, if it indeed
rejects
a Cookie header containing any non-US-ASCII character (whether in the
cookie
name or value).
- That the error message could be improved (é is not a control
character, it's just invalid here)
- but that the real fix for the OP may be to Base64-encode the cookie
value before sending it to the browser.
That's also because it may happen one day that even a browser which
respects the specs to the letter (one never knows), could reject a value
like : abcé,abc,abc,abc,abc,abc,abc,abc,abc;
[1] http://tools.ietf.org/search/rfc2616
[2] http://tools.ietf.org/search/rfc6265
[3] http://tools.ietf.org/search/rfc6265#section-4.1.1
As an appendix, and triggered by another post to this list, here is
another
way of encoding HTTP header values :
Cookie: ACE_COOKIE=R660302447; TD3World=R760446058
SM_TRANSACTIONID:
=?UTF-8?B?MGE2NDA2MDEtNDAzMy01MjdjYzlkMy0wMDBhLTJjMWI0NjJi?=
SM_AUTHTYPE: =?UTF-8?B?QXV0bw==?=
SM_SDOMAIN: =?UTF-8?B?LnRveW90YS1ldXJvcGUuY29t?=
In this case, the cookie values are encoded using a MIME extension
scheme
which indicates (between =? ? ?) prior to a string's value, the character
set/encoding in which the subsequent string is to be interpreted.
This is not explicitly mentioned in any of the above references, but as I
recall, this is part of another series of RFC's,
Re: cookie issue with Tomcat 7 - does not accept the character é
Cookie handling is fundamentally a complete mess. Specifications exist but are not fully implemented, are not consistent with related specifications, etc. Having tried to sort this out the last time around and having read Jeremy's great work on documenting where we stand at the present moment, it often feels like it wouldn't be too hard to make a case that just about any cookie name or value that isn't an token (as per RFC2616) is either valid or invalid depending on which specification(s) you choose to read. I'd strongly encourage anyone thinking about commenting further on this thread to take the time to read the wiki page [1] where the Tomcat committers (and Jeremy in particular) are currently trying to figure out exactly how Tomcat should handle cookies in the future. Mark [1] http://wiki.apache.org/tomcat/Cookies - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7.0.50 on IBM i series - System i V7R1 - Installation errors
Hi Konstantin/Daniel, We are using Java 1.6. The gnu.xml has not been installed separately. It must have been a part of the Tomcat installation. The XML parser is whatever comes default with Tomcat. We did a copy of the working copy of Tomcat (7.0.50) from the Development box to the production box. Both are running on the same release of the software V7R1 and the patches are also similar as they get applied simultaneously. The only difference in libraries is a library provided by Robot on the production box which is RBTSYSLIB.LIB. Not sure what is happening on the production box with Tomcat as we are still not too familiar with the startup requirements of Tomcat. We have not even copied our application. All indications seem to be a JVM and Java or path problem like you indicated but not sure how to get to the bottom of the problem. Is there a verbose way of starting up Tomcat where we can exactly see where it gets stuck up other than the log file. We are not getting much information on this log file at all. Regards Shekar -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Sunday, February 02, 2014 11:24 AM To: Tomcat Users List Subject: Re: Tomcat 7.0.50 on IBM i series - System i V7R1 - Installation errors 2014-02-01 Jakati, Shekar shekar.jak...@lfg.com: Hello friends, We are new to using Tomcat. Installed Apache Tomcat on our development box and runs great. Tried to install Apache 7.0.50 on our production box with similar configuration i.e. 'IBM Series System I running V7R1 'and get the below error. Part of the catalina.2014-01-31 log file is attached. Unable to figure out what is causing this problem. Any help or pointers is much appreciated. *** Jan 31, 2014 9:55:56 AM org.apache.catalina.core.AprLifecycleListener init Jan 31, 2014 10:02:26 AM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [http-bio-8080] Jan 31, 2014 10:02:27 AM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [ajp-bio-8009] Jan 31, 2014 10:02:27 AM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Catalina Jan 31, 2014 10:02:27 AM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler [http-bio-8080] Jan 31, 2014 10:02:27 AM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler [ajp-bio-8009] Jan 31, 2014 10:02:28 AM org.apache.coyote.AbstractProtocol destroy INFO: Destroying ProtocolHandler [http-bio-8080] Jan 31, 2014 10:02:28 AM org.apache.coyote.AbstractProtocol destroy INFO: Destroying ProtocolHandler [ajp-bio-8009] Jan 31, 2014 10:03:05 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /QSYS.LIB/NQSYS.LIB:/QSYS.LIB:/QSYS.LIB/QSYS2.LIB:/QSYS.LIB/QHLPSYS.LI B:/QSYS.LIB/QUSRSYS.LIB:/QSYS.LIB/RBTSYSLIB.LIB:/QSYS.LIB/QSHELL.LIB:/ QSYS.LIB/TOMCAT.LIB:/QSYS.LIB/QTEMP.LIB:/QOpenSys/QIBM/ProdData/JavaVM /jdk70/32bit/jre/lib/ppc:/QOpenSys/QIBM/ProdData/JavaVM/jdk70/32bit/jr e/lib/ppc/classic:/QOpenSys/QIBM/ProdData/JavaVM/jdk70/32bit/jre/lib/p pc/default:/QOpenSys/QIBM/ProdData/JavaVM/jdk70/32bit/jre/bin:/QOpenSy s/QIBM/ProdData/JavaVM/jdk70/32bit/jre/bin/classic Jan 31, 2014 10:03:06 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-bio-8080] Jan 31, 2014 10:03:07 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [ajp-bio-8009] Jan 31, 2014 10:03:07 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2377 ms Jan 31, 2014 10:03:07 AM org.apache.catalina.users.MemoryUserDatabase open WARNING: Exception configuring digester to permit java encoding names in XML files. Only IANA encoding names will be supported. org.xml.sax.SAXNotRecognizedException: http://apache.org/xml/features/allow-java-encodings at gnu.xml.aelfred2.JAXPFactory.setFeature(JAXPFactory.java:102) gnu.xml package?! What JVM and XML parser are you using? Jan 31, 2014 10:03:07 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Jan 31, 2014 10:03:07 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.50 Jan 31, 2014 10:03:07 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /Tomcat/apache-tomcat-7.0.50/webapps/ROOT Jan 31, 2014 10:03:07 AM org.apache.catalina.startup.HostConfig deployDirectory SEVERE: Error deploying web application directory /Tomcat/apache-tomcat-7.0.50/webapps/ROOT (...) Caused by: java.lang.NullPointerException at org.apache.tomcat.util.descriptor.DigesterFactory.idFor(DigesterFactory.java:107) at
Re: Tomcat 5 Repository
On Tue, Feb 4, 2014 at 4:08 AM, Konstantin Kolinko knst.koli...@gmail.comwrote: On Wed, Jan 29, 2014 at 2:59 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: At least you've got the right mailing list this time. No idea where you were looking, but the 5.0 and 5.5 are pretty obvious when you look in the places linked to from the Tomcat home page: http://archive.apache.org/dist/tomcat/ http://svn.apache.org/repos/asf/tomcat/archive/ 2014-02-03 Pavneet singh Kochhar kochha...@gmail.com: Thanks for the help Chuck! 1. Follow the rules http://tomcat.apache.org/lists.html#tomcat-users - 6. Do not top-post. OK I checked the svn repository but coudn't really figure out how to get the commit logs which shows the files changed for Tomcat5. The commits show something like r588813 | markt | 2007-10-27 08:11:17 +0800 (Sat, 27 Oct 2007) | 1 line archive prep r588811 | markt | 2007-10-27 08:10:25 +0800 (Sat, 27 Oct 2007) | 1 line Create folder for 5.0.x archive which I believe are related to adding files to archive etc. However, I require the files changed during commits. 2. What are you trying to do and why? What is your goal? I am a researcher and want to examine the commit logs of Tomcat5. I have some bug reports associated with Tomcat5 and I wish to know which commits fixed a particular bug correspondingly which files were changed to fix that bug. 3. What tools are you using? Do you know how to use those tools? Currently I am using SVN to examine the commit logs. 4. Tomcat 5.5 and earlier consist of several components (build, connectors, container, jasper, servletapi). Each of those was a separate project. Each of those had its own trunk/tags/branches structure Each of those has its own svn history. I am interested in commit logs related to all the components since I would want to know which files were changed during bug fixing. 5. Source code for older versions of Tomcat was migrated from CVS. CVS does not save history when files are renamed or copied. Ok, is it possible to get the CVS repository or any other option where I can get commit logs. If you are looking for an old change, you may have to look for Tomcat 4 or earlier sources for the same-named file. No, i am only interested in commit logs associated with Tomcat5. 6. All commit e-mails can be found in mailing list archives. Ok In short, I need all the commit logs (Tomcat5 only) which I can examine to find the fixes for bugs. From these fixes, I can get the information about the files changed. Thanks for the help! Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
