RE: Content_Length Problem
From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a
Re: Content_Length Problem
Joe, Tim is right. It's not necessary a problem of the webapp. If content is dynamic and it doesn't make much sense to set content-length before the response, when using AJP it's the responsibility of the web server to handle the dynamic nature of the response. AJP itself knows how to signal the end of the response, and Apache httpd automatically converts such a dynamic reponse (better: one that didn't come from the backend with a content-length) into chunked encoding. Our IIS redirector instead closes the connection, which is another way of signaling the end of the response. It looks like the CICS people have to improve their HTTP implementation to support at least one of those two cases, and then you can choose the appropriate web server. Regards, Rainer Tim Whittington schrieb: From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file
tomcat 5.0.28 and SSL setup
My problem: Port 8443 won't open. But I can see port 8080.
Running Tomcat 5.0.28 on Mac OS 10.4.11 (no firewall yet).
I'm not using a self-assigned cert. I created a CSR request, got my
certs and have imported my certs in the following order using
Terminal. Everything I have researched says they have to be
installed in a particular order or the will not work.:
root - AddTrustExternalCARoot.crt
inter - UTNAddTrustServer_CA.crt
chain - NetworkSolutions_CA.crt
tomcat - mydomain.com.crt
(My keystore is located my user's home directory along with a folder
that has the certs in it.)
If I printcerts in Terminal, they look good to me compared to
documentation and examples online. (howeverI'm a newbie.)
I have uncommented the connector port in the server.xml config.
Connector port=8443
maxThreads=100 minSpareThreads=5
maxSpareThreads=25
enableLookups=false disableUploadTimeout=true
acceptCount=100 debug=0 scheme=https secure=true
clientAuth=false sslProtocol=TLS
keyAlias=tomcat keystoreFile=/Users/machine/.keystore
keystorePass=... /
Tomcat Log shows:
2008-01-05 07:25:56 StandardContext[/servlets-examples]
ContextListener: attributeReplaced
('org.apache.catalina.WELCOME_FILES', '[Ljava.lang.String;@8e7b84')
2008-01-05 07:25:56 StandardContext[/servlets-examples]
ContextListener: attributeReplaced
('org.apache.catalina.WELCOME_FILES', '[Ljava.lang.String;@4f53eb')
2008-01-05 07:25:56 StandardContext[/servlets-examples]
ContextListener: attributeReplaced
('org.apache.catalina.WELCOME_FILES', '[Ljava.lang.String;@e6b82')
2008-01-05 07:25:56 StandardContext[/servlets-examples]
SessionListener: contextDestroyed()
2008-01-05 07:25:56 StandardContext[/servlets-examples]
ContextListener: contextDestroyed()
2008-01-05 07:25:56 StandardContext[/jsp-examples]ContextListener:
attributeReplaced('org.apache.catalina.WELCOME_FILES',
'[Ljava.lang.String;@8e45a8')
2008-01-05 07:25:56 StandardContext[/jsp-examples]ContextListener:
attributeReplaced('org.apache.catalina.WELCOME_FILES',
'[Ljava.lang.String;@7f3202')
2008-01-05 07:25:56 StandardContext[/jsp-examples]ContextListener:
attributeReplaced('org.apache.catalina.WELCOME_FILES',
'[Ljava.lang.String;@ac5c8b')
2008-01-05 07:25:56 StandardContext[/jsp-examples]SessionListener:
contextDestroyed()
2008-01-05 07:25:56 StandardContext[/jsp-examples]ContextListener:
contextDestroyed()
2008-01-05 07:29:44 StandardContext[/balancer]Exception starting
filter BalancerFilter
java.lang.NoClassDefFoundError: org/apache/commons/digester/Digester
at org.apache.webapp.balancer.RulesParser.createDigester
(RulesParser.java:65)
at org.apache.webapp.balancer.RulesParser.init(RulesParser.java:43)
at org.apache.webapp.balancer.BalancerFilter.init
(BalancerFilter.java:79)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter
(ApplicationFilterConfig.java:225)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef
(ApplicationFilterConfig.java:308)
at org.apache.catalina.core.ApplicationFilterConfig.init
(ApplicationFilterConfig.java:79)
at org.apache.catalina.core.StandardContext.filterStart
(StandardContext.java:3698)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:4349)
at org.apache.catalina.core.ContainerBase.addChildInternal
(ContainerBase.java:823)
at org.apache.catalina.core.ContainerBase.addChild
(ContainerBase.java:807)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:
595)
at org.apache.catalina.core.StandardHostDeployer.install
(StandardHostDeployer.java:277)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
at org.apache.catalina.startup.HostConfig.deployDirectories
(HostConfig.java:701)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:
432)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:349)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1083)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:
478)
at org.apache.catalina.core.StandardService.start
(StandardService.java:480)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:
2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at
Re: org.apache.commons.digester.Digester endElement (Q A)
What I see below is a comment !-- -- block that does not encompass both the beginning and ending Context elements. This would fail if run through a XML validator. If the begin element is in the comment, so should it's corresponding end element. Additionally be careful you don't try to nest comments. !-- Some comment !-- Another comment -- -- does not work. --David Albretch Mueller wrote: if you find exceptions looking like this: ~ org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:217) at org.apache.commons.digester.Rule.end(Rule.java:253) at org.apache.commons.digester.Digester.endElement(Digester.java:1222) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) . . . ~ it means what is says ;-) ~ but what I think is wrong is that TC conf parsers apparently attempt to parse into the comments so that if you have some not well-formed xml inside the comments, such as: ~ !-- Context configuration file for the Tomcat Administration Web App $Id: admin.xml 288428 2002-07-23 12:12:15Z remm $ W Box at Work: Context docBase=C:\cmllpz\prjx\java\GWB\tc\tc-4.1.36\server\webapps\admin Logger directory=C:\cmllpz\prjx\java\GWB\logs -- ~ they would pick it up ~ I was using TC 4.1.36 but I think this is a bug. After being fed a start comment, !--, sequence parsers should not attempt to resume parsing till they fully get an ending, --, one ~ Or? ~ lbrtchx - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: org.apache.commons.digester.Digester endElement (Q A)
I just realized what you posted was just a very narrow excerpt of the comment block only. Could you provide a complete example? --David David Smith wrote: What I see below is a comment !-- -- block that does not encompass both the beginning and ending Context elements. This would fail if run through a XML validator. If the begin element is in the comment, so should it's corresponding end element. Additionally be careful you don't try to nest comments. !-- Some comment !-- Another comment -- -- does not work. --David Albretch Mueller wrote: if you find exceptions looking like this: ~ org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:217) at org.apache.commons.digester.Rule.end(Rule.java:253) at org.apache.commons.digester.Digester.endElement(Digester.java:1222) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) . . . ~ it means what is says ;-) ~ but what I think is wrong is that TC conf parsers apparently attempt to parse into the comments so that if you have some not well-formed xml inside the comments, such as: ~ !-- Context configuration file for the Tomcat Administration Web App $Id: admin.xml 288428 2002-07-23 12:12:15Z remm $ W Box at Work: Context docBase=C:\cmllpz\prjx\java\GWB\tc\tc-4.1.36\server\webapps\admin Logger directory=C:\cmllpz\prjx\java\GWB\logs -- ~ they would pick it up ~ I was using TC 4.1.36 but I think this is a bug. After being fed a start comment, !--, sequence parsers should not attempt to resume parsing till they fully get an ending, --, one ~ Or? ~ lbrtchx - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running Tomcat as Standalone in linux
Hi guys,
I want to serve a site with few graphics so I decided to use Tomcat 5.5 as my
server. But I'm having difficulty getting it to run on port 80. I read
http://www.ibm.com/developerworks/java/library/l-secjav.html and decided to try
xinetd. I added this to /etc/xinetd/:
# Redirects any port 80 requests to port 8180 (to Tomcat)
service tomcat
{
socket_type= stream
protocol= tcp
user= root
wait= no
port= 80
redirect= localhost 8180
disable= no
}
it works great on that machine if I point my browser but remotely I get zilch.
I've tried plugging in my ip address instead of localhost: zilch. Could anyone
point me in the right direction?
Thanks.
Chris
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
RE: Running Tomcat as Standalone in linux
verify the listen address is broadcasting on port 80 on the web-server
e.g.?netstat -a | grep
80Martin__Disclaimer and
confidentiality noteEverything in this e-mail and any attachments relates to
the official business of Sender. This transmission is of a confidential nature
and Sender does not endorse distribution to any party other than intended
recipient. Sender does not necessarily endorse content contained within this
transmission. Date: Sat, 5 Jan 2008 23:49:13 +0800 From: [EMAIL PROTECTED]
To: users@tomcat.apache.org Subject: Re: Running Tomcat as Standalone in
linux Check out your log see if there is any error info. On Jan 5, 2008
11:29 PM, Chris Baty [EMAIL PROTECTED] wrote: Hi guys, I want to
serve a site with few graphics so I decided to use Tomcat 5.5 as my server.
But I'm having difficulty getting it to run on port 80. I read
http://www.ibm.com/developerworks/java/library/l-secjav.html and decided to
try xinetd. I added this to /etc/xinetd/: # Redirects any port 80 requests
to port 8180 (to Tomcat) service tomcat { socket_type = stream
protocol = tcp user = root wait = no port = 80 redirect = localhost
8180 disable = no } it works great on that machine if I point my
browser but remotely I get zilch. I've tried plugging in my ip address
instead of localhost: zilch. Could anyone point me in the right direction?
Thanks. Chris
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
Re: Running Tomcat as Standalone in linux
Check out your log see if there is any error info.
On Jan 5, 2008 11:29 PM, Chris Baty [EMAIL PROTECTED] wrote:
Hi guys,
I want to serve a site with few graphics so I decided to use Tomcat 5.5 as
my server. But I'm having difficulty getting it to run on port 80. I
read http://www.ibm.com/developerworks/java/library/l-secjav.html and
decided to try xinetd. I added this to /etc/xinetd/:
# Redirects any port 80 requests to port 8180 (to Tomcat)
service tomcat
{
socket_type= stream
protocol= tcp
user= root
wait= no
port= 80
redirect= localhost 8180
disable= no
}
it works great on that machine if I point my browser but remotely I get
zilch. I've tried plugging in my ip address instead of localhost: zilch.
Could anyone point me in the right direction?
Thanks.
Chris
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Running Tomcat as Standalone in linux
This is what I get:
[1]+ Stopped man netstat
batybase:~# netstat -a | grep 80
tcp6 0 0 localhost:8005 *:* LISTEN
tcp6 0 0 *:8009 *:* LISTEN
tcp6 0 0 *:8180 *:* LISTEN
unix 2 [ ACC ] STREAM LISTENING 6880
/tmp/ksocket-root/klauncherPeUbjb.slave-socket
unix 2 [ ] DGRAM5680
@/org/freedesktop/hal/udev_event
unix 3 [ ] STREAM CONNECTED 7780
/tmp/ksocket-root/klauncherPeUbjb.slave-socket
unix 3 [ ] STREAM CONNECTED 7280
unix 3 [ ] STREAM CONNECTED 6802
/tmp/orbit-root/linc-9cb-0-12bc601ddc9d
unix 3 [ ] STREAM CONNECTED 6801
unix 3 [ ] STREAM CONNECTED 6800
/tmp/orbit-root/linc-9db-0-4edea2c4bde82
logs are normal.
How do I add a listening port?
Thanks.
Chris
- Original Message
From: Martin Gainty [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Saturday, January 5, 2008 10:56:40 AM
Subject: RE: Running Tomcat as Standalone in linux
verify the listen address is broadcasting on port 80 on the web-server
e.g.?netstat -a | grep
80Martin__Disclaimer and
confidentiality noteEverything in this e-mail and
any attachments relates to the official business of Sender. This
transmission is of a confidential nature and Sender does not endorse
distribution to any party other than intended recipient. Sender does not
necessarily endorse content contained within this transmission. Date: Sat, 5
Jan 2008 23:49:13 +0800 From: [EMAIL PROTECTED] To:
users@tomcat.apache.org Subject: Re: Running Tomcat as Standalone in
linux Check out your log see if there is any error info. On Jan 5,
2008 11:29 PM, Chris Baty [EMAIL PROTECTED] wrote: Hi guys,
I want to serve a site with few graphics so I decided to use Tomcat
5.5 as my server. But I'm having difficulty getting it to run on port
80. I read
http://www.ibm.com/developerworks/java/library/l-secjav.html and
decided to try xinetd. I added this to /etc/xinetd/: # Redirects any
port 80 requests to port 8180 (to Tomcat) service tomcat {
socket_type = stream protocol = tcp user = root wait = no port =
80 redirect = localhost 8180 disable = no } it works great
on that machine if I point my browser but remotely I get zilch.
I've tried plugging in my ip address instead of localhost: zilch. Could
anyone point me in the right direction? Thanks. Chris
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_
Make distant family not so distant with Windows Vista® + Windows
Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
RE: Content_Length Problem
Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm do you need IIS running..is there a way to perhaps use Apache with mod_jk just to ensure http-1.1 chunked encoding/content-length bilateral connections are supported? Then once all your staging environments are operational then sub in IIS with all those mysterious dlls? Martin __Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: RE: Content_Length Problem Date: Sat, 5 Jan 2008 22:41:31 +1300 From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length
Re: Content_Length Problem
In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Tomcat as Standalone in linux
Chris Baty wrote: batybase:~# netstat -a | grep 80 tcp6 0 0 localhost:8005 *:* LISTEN tcp6 0 0 *:8009 *:* LISTEN tcp6 0 0 *:8180 *:* LISTEN This doesn't show any process listening on tcp port 80. It would be surprising if accessing Tomcat via port 80 would work at all - regardless whether the client is running on the local or a remote machine. Is XInetd running? BTW: if you're only interested in the apps listening on tcp ports and don't want numbers to be converted to names, use netstat -tlpn logs are normal. What logs? What is normal? How do I add a listening port? Add a port to what? BTW: If you connect via XInetd's redirect feature, from Tomcat's point of view every connection will come from the machine running XInetd. That might or might not be an issue for you, but you should be aware of it. As an alternative, you might want to consider using jsvc, which allows Tomcat to bind to a privileged port and drop privileges immediately afterwards. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Hi Gregory,
the descriptions below work (at least) for TC 5.0/5.5/6.0.
Gregory Gerard schrieb:
I've got an F5 load balancer running version 9.3 of the software.
I've got several Tomcat installations behind it.
The F5 does all SSL and clear traffic as a reverse proxy, rewriting
headers as needed for cookies and whatnot.
I have one connector on 8080 for the clear traffic.
My problem: I tried to add another connector on 8081 setting secure to
true so that the HttpServletRequest would say, yup, this is a secure
connection and tell the 8080 connector 8081 is the secure address it
should use when trying to upshift to higher security.
Don't use secure, use scheme=https instead. See
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
When I did this and started Tomcat up, it whined about not being able to
open up my keystore.
I want all my SSL to offloaded and keep the keys out of each machine and
centrally managed. I *just* want to get the servlets to believe the
connection is secure. This is analogous to HTTPd doing the SSL offload
with the mod_jk connector.
Also, the header X-Forwarded-For is set by the F5 and I'd like the
Connector to also give out this IP instead of the load balancer's.
I assume you are talking about the access log?
For common log format, but using the client IP, you take the pattern:
%{X-Forwarded-For}i %l %u %t quot;%rquot; %s %b
See:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Caution: X-Forwarded-For can contain multiple IP addresses, if the
request passed through multiple proxies and they are configured to add
IPs, not to overwrite. Keep this in mind when doing analysis on the field.
Any ideas short of recompiling Tomcat with a modified connector? Anyone
else faced this problem?
There should be no need for code changes :)
thanks,
greg
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Thanks! I'll give that a whirl. So you're saying that my marking it as
scheme='https' HttpServletRequest.isSecure() will respond with true?
Good to know about the multiple IPs... Didn't know that was legal but
makes sense.
Logging would be fine (though I don't know how the access log would
handle it when parsed) but I'm more trying to get
HttpServletRequest.getRemoteAddr()/getRemoteHost to return outer-most
value (which I would make the assumption that it's the browser's address).
greg
Rainer Jung wrote:
Hi Gregory,
the descriptions below work (at least) for TC 5.0/5.5/6.0.
Gregory Gerard schrieb:
I've got an F5 load balancer running version 9.3 of the software.
I've got several Tomcat installations behind it.
The F5 does all SSL and clear traffic as a reverse proxy, rewriting
headers as needed for cookies and whatnot.
I have one connector on 8080 for the clear traffic.
My problem: I tried to add another connector on 8081 setting secure
to true so that the HttpServletRequest would say, yup, this is a
secure connection and tell the 8080 connector 8081 is the secure
address it should use when trying to upshift to higher security.
Don't use secure, use scheme=https instead. See
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
When I did this and started Tomcat up, it whined about not being able
to open up my keystore.
I want all my SSL to offloaded and keep the keys out of each machine
and centrally managed. I *just* want to get the servlets to believe
the connection is secure. This is analogous to HTTPd doing the SSL
offload with the mod_jk connector.
Also, the header X-Forwarded-For is set by the F5 and I'd like the
Connector to also give out this IP instead of the load balancer's.
I assume you are talking about the access log?
For common log format, but using the client IP, you take the pattern:
%{X-Forwarded-For}i %l %u %t quot;%rquot; %s %b
See:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Caution: X-Forwarded-For can contain multiple IP addresses, if the
request passed through multiple proxies and they are configured to add
IPs, not to overwrite. Keep this in mind when doing analysis on the
field.
Any ideas short of recompiling Tomcat with a modified connector?
Anyone else faced this problem?
There should be no need for code changes :)
thanks,
greg
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Sorry didn't read your post carefully enough. The access log thing is OK, but about the redirect: I've got an F5 load balancer running version 9.3 of the software. I've got several Tomcat installations behind it. The F5 does all SSL and clear traffic as a reverse proxy, rewriting headers as needed for cookies and whatnot. I have one connector on 8080 for the clear traffic. My problem: I tried to add another connector on 8081 setting secure to true so that the HttpServletRequest would say, yup, this is a secure connection and tell the 8080 connector 8081 is the secure address it should use when trying to upshift to higher security. Concerning redirects from http to https: what about attribute redirectPort on the 8080 connector? But of course you need to set it to a port, that's available on the F5. I want all my SSL to offloaded and keep the keys out of each machine and centrally managed. I *just* want to get the servlets to believe the connection is secure. This is analogous to HTTPd doing the SSL offload with the mod_jk connector. Can you give your full connector 8081 configuration? Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
I've got an F5 load balancer running version 9.3 of the software. I've got several Tomcat installations behind it. The F5 does all SSL and clear traffic as a reverse proxy, rewriting headers as needed for cookies and whatnot. I have one connector on 8080 for the clear traffic. My problem: I tried to add another connector on 8081 setting secure to true so that the HttpServletRequest would say, yup, this is a secure connection and tell the 8080 connector 8081 is the secure address it should use when trying to upshift to higher security. When I did this and started Tomcat up, it whined about not being able to open up my keystore. I want all my SSL to offloaded and keep the keys out of each machine and centrally managed. I *just* want to get the servlets to believe the connection is secure. This is analogous to HTTPd doing the SSL offload with the mod_jk connector. Also, the header X-Forwarded-For is set by the F5 and I'd like the Connector to also give out this IP instead of the load balancer's. Any ideas short of recompiling Tomcat with a modified connector? Anyone else faced this problem? thanks, greg - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
In Tomcat 6.0.x you can do Connector port=8081 SSLEnabled=false secure=true scheme=https ... In Tomcat 5.5.x you can write a Filter that creates a HttpServletRequestWrapper, that returns true on isSecure, and https on getScheme or you can take a look at org.apache.catalina.valves.SSLValve, which reads headers set by the server in front, most commonly apache httpd Filip Gregory Gerard wrote: I've got an F5 load balancer running version 9.3 of the software. I've got several Tomcat installations behind it. The F5 does all SSL and clear traffic as a reverse proxy, rewriting headers as needed for cookies and whatnot. I have one connector on 8080 for the clear traffic. My problem: I tried to add another connector on 8081 setting secure to true so that the HttpServletRequest would say, yup, this is a secure connection and tell the 8080 connector 8081 is the secure address it should use when trying to upshift to higher security. When I did this and started Tomcat up, it whined about not being able to open up my keystore. I want all my SSL to offloaded and keep the keys out of each machine and centrally managed. I *just* want to get the servlets to believe the connection is secure. This is analogous to HTTPd doing the SSL offload with the mod_jk connector. Also, the header X-Forwarded-For is set by the F5 and I'd like the Connector to also give out this IP instead of the load balancer's. Any ideas short of recompiling Tomcat with a modified connector? Anyone else faced this problem? thanks, greg - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Gregory Gerard schrieb:
Thanks! I'll give that a whirl. So you're saying that my marking it as
scheme='https' HttpServletRequest.isSecure() will respond with true?
No, sorry, see my second post. The attribute scheme is used when a
self-referencing redirect gets constructed. That's a way of producing a
httpd redirect, although technically the reuqest is http.
secure should do what you want. Please post your connector configuration.
Good to know about the multiple IPs... Didn't know that was legal but
makes sense.
Logging would be fine (though I don't know how the access log would
handle it when parsed) but I'm more trying to get
HttpServletRequest.getRemoteAddr()/getRemoteHost to return outer-most
value (which I would make the assumption that it's the browser's address).
No idea about the getRemote*.
Others?
mod_jk corrsponds with the AJP connector, and this connector fakes those
getRemote* from the info retrieved by mod_jk.
greg
Rainer Jung wrote:
Hi Gregory,
the descriptions below work (at least) for TC 5.0/5.5/6.0.
Gregory Gerard schrieb:
I've got an F5 load balancer running version 9.3 of the software.
I've got several Tomcat installations behind it.
The F5 does all SSL and clear traffic as a reverse proxy, rewriting
headers as needed for cookies and whatnot.
I have one connector on 8080 for the clear traffic.
My problem: I tried to add another connector on 8081 setting secure
to true so that the HttpServletRequest would say, yup, this is a
secure connection and tell the 8080 connector 8081 is the secure
address it should use when trying to upshift to higher security.
Don't use secure, use scheme=https instead. See
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
When I did this and started Tomcat up, it whined about not being able
to open up my keystore.
I want all my SSL to offloaded and keep the keys out of each machine
and centrally managed. I *just* want to get the servlets to believe
the connection is secure. This is analogous to HTTPd doing the SSL
offload with the mod_jk connector.
Also, the header X-Forwarded-For is set by the F5 and I'd like the
Connector to also give out this IP instead of the load balancer's.
I assume you are talking about the access log?
For common log format, but using the client IP, you take the pattern:
%{X-Forwarded-For}i %l %u %t quot;%rquot; %s %b
See:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Caution: X-Forwarded-For can contain multiple IP addresses, if the
request passed through multiple proxies and they are configured to add
IPs, not to overwrite. Keep this in mind when doing analysis on the
field.
Any ideas short of recompiling Tomcat with a modified connector?
Anyone else faced this problem?
There should be no need for code changes :)
thanks,
greg
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Tomcat as Standalone in linux
Chris Baty escribío:
Hi guys,
I want to serve a site with few graphics so I decided to use Tomcat 5.5 as my
server. But I'm having difficulty getting it to run on port 80. I read
http://www.ibm.com/developerworks/java/library/l-secjav.html and decided to try
xinetd. I added this to /etc/xinetd/:
# Redirects any port 80 requests to port 8180 (to Tomcat)
service tomcat
{
socket_type= stream
protocol= tcp
user= root
wait= no
port= 80
redirect= localhost 8180
disable= no
}
it works great on that machine if I point my browser but remotely I get zilch.
I've tried plugging in my ip address instead of localhost: zilch. Could anyone
point me in the right direction?
Thanks.
Chris
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
You can also use the java service launcher that is located in the bin directory
of the distribution. You need to compile it and install it. What it does is
launch tomcat on port 80 as root, but changes the owner to be something else,
like 'tomcat'. That way, you can run it on port 80, but not as root.
A way of launching it from say /etc/init.d is with a script like the following:
#!/bin/sh
#
# chkconfig: 345 86 15
# description: Tomcat Server
#
# Small shell script to show how to start/stop Tomcat using jsvc
# If you want to have Tomcat running on port 80 please modify the server.xml
# file:
#
#!-- Define a non-SSL HTTP/1.1 Connector on port 80 --
#Connector className=org.apache.catalina.connector.http.HttpConnector
# port=80 minProcessors=5 maxProcessors=75
# enableLookups=true redirectPort=8443
# acceptCount=10 debug=0 connectionTimeout=6/
#
#
# Adapt the following lines to your configuration
JAVA_HOME=/usr/jdk
CATALINA_HOME=/opt/tomcat
CATALINA_BASE=/opt/webBaseDir
DAEMON_HOME=/usr/local/bin
TOMCAT_USER=tomcat
TMP_DIR=$CATALINA_BASE/temp
CATALINA_OPTS= -Djava.library.path=/usr/local/apr/lib
-Djava.awt.headless=true
-Xms128M -Xmx512M
-XX:+UseParallelOldGC
CLASSPATH=\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/tomcat-juli.jar:\
$CATALINA_HOME/bin/bootstrap.jar
case $1 in
start)
#
# Start Tomcat
#
$DAEMON_HOME/jsvc \
-user $TOMCAT_USER \
-home $JAVA_HOME \
-jvm server \
-Dcatalina.home=$CATALINA_HOME \
-Dcatalina.base=$CATALINA_BASE \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
-Djava.endorsed.dirs=$CATALINA_BASE/endorsed \
-Djava.io.tmpdir=$TMP_DIR \
-outfile $CATALINA_BASE/logs/catalina.out \
-errfile '1' \
$CATALINA_OPTS \
-cp $CLASSPATH \
org.apache.catalina.startup.Bootstrap
#
# To get a verbose JVM
#-verbose \
# To get a debug of jsvc.
#-debug \
;;
stop)
#
# Stop Tomcat
#
PID=`cat /var/run/jsvc.pid`
kill $PID
;;
*)
echo Usage tomcat.sh start/stop
exit 1
;;
esac
--
Brian Millett - [ Ivanova, The Geometry of Shadows]
If it gets too bad I'll just gnaw it off at the ankle.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Rainer Jung wrote:
Hi Gregory,
the descriptions below work (at least) for TC 5.0/5.5/6.0.
Gregory Gerard schrieb:
I've got an F5 load balancer running version 9.3 of the software.
I've got several Tomcat installations behind it.
The F5 does all SSL and clear traffic as a reverse proxy, rewriting
headers as needed for cookies and whatnot.
I have one connector on 8080 for the clear traffic.
My problem: I tried to add another connector on 8081 setting secure
to true so that the HttpServletRequest would say, yup, this is a
secure connection and tell the 8080 connector 8081 is the secure
address it should use when trying to upshift to higher security.
Don't use secure, use scheme=https instead. See
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
on tomcat 6, use both secure=true and scheme=https, just set
SSLEnabled=false
When I did this and started Tomcat up, it whined about not being able
to open up my keystore.
I want all my SSL to offloaded and keep the keys out of each machine
and centrally managed. I *just* want to get the servlets to believe
the connection is secure. This is analogous to HTTPd doing the SSL
offload with the mod_jk connector.
Also, the header X-Forwarded-For is set by the F5 and I'd like the
Connector to also give out this IP instead of the load balancer's.
I assume you are talking about the access log?
For common log format, but using the client IP, you take the pattern:
%{X-Forwarded-For}i %l %u %t quot;%rquot; %s %b
See:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Caution: X-Forwarded-For can contain multiple IP addresses, if the
request passed through multiple proxies and they are configured to add
IPs, not to overwrite. Keep this in mind when doing analysis on the
field.
Remember, that you can configure F5 to not modify the src address of
TCP, so that you get a true idea of where the connection is coming from.
Look through your F5 manuals.
Filip
Any ideas short of recompiling Tomcat with a modified connector?
Anyone else faced this problem?
There should be no need for code changes :)
thanks,
greg
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.20+ behind an F5 Load Balancer doing SSL Connector problem
Gregory Gerard wrote:
Thanks! I'll give that a whirl. So you're saying that my marking it as
scheme='https' HttpServletRequest.isSecure() will respond with true?
Good to know about the multiple IPs... Didn't know that was legal but
makes sense.
Logging would be fine (though I don't know how the access log would
handle it when parsed) but I'm more trying to get
HttpServletRequest.getRemoteAddr()/getRemoteHost to return outer-most
value (which I would make the assumption that it's the browser's
address).
this is a configuration on the F5, read the manual for that.
Filip
greg
Rainer Jung wrote:
Hi Gregory,
the descriptions below work (at least) for TC 5.0/5.5/6.0.
Gregory Gerard schrieb:
I've got an F5 load balancer running version 9.3 of the software.
I've got several Tomcat installations behind it.
The F5 does all SSL and clear traffic as a reverse proxy, rewriting
headers as needed for cookies and whatnot.
I have one connector on 8080 for the clear traffic.
My problem: I tried to add another connector on 8081 setting secure
to true so that the HttpServletRequest would say, yup, this is a
secure connection and tell the 8080 connector 8081 is the secure
address it should use when trying to upshift to higher security.
Don't use secure, use scheme=https instead. See
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
When I did this and started Tomcat up, it whined about not being
able to open up my keystore.
I want all my SSL to offloaded and keep the keys out of each machine
and centrally managed. I *just* want to get the servlets to believe
the connection is secure. This is analogous to HTTPd doing the SSL
offload with the mod_jk connector.
Also, the header X-Forwarded-For is set by the F5 and I'd like the
Connector to also give out this IP instead of the load balancer's.
I assume you are talking about the access log?
For common log format, but using the client IP, you take the pattern:
%{X-Forwarded-For}i %l %u %t quot;%rquot; %s %b
See:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
Caution: X-Forwarded-For can contain multiple IP addresses, if the
request passed through multiple proxies and they are configured to
add IPs, not to overwrite. Keep this in mind when doing analysis on
the field.
Any ideas short of recompiling Tomcat with a modified connector?
Anyone else faced this problem?
There should be no need for code changes :)
thanks,
greg
Regards,
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
