Tomcat 5.5 won't do TLS
I'm trying to enable TLS (or SSL) in a Tomcat 5.5.29 server, on a Windows XP machine. Whatever I do, I always end up with a server that just delivers plain HTML on port 443, and it doesn't even try to use TLS. That is, I can connect to http://localhost:443/ and get the same as http://localhost/ and https://localhost/ just displays an invalid response error which makes perfect sense because the webserver isn't attempting TLS negotiation at all. So far, I've followed various recipes for creating a selfsigned key that Tomcat might want to use, but I am suspecting now that the key is not the problem at all, because there is no error whatsoever in the log files. All my attempts have by now been accompagnied by completely removing Tomcat, removing all left-over directories and installing it again before attempting anything else. The only change to the configuration is in conf/server.xml, I changed the connectors: !-- Define a non-SSL HTTP/1.1 Connector on port 80 -- Connector port=80 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=2 maxSpareThreads=75 enableLookups=false redirectPort=443 acceptCount=10 connectionTimeout=2 disableUploadTimeout=true / !-- Define a SSL HTTP/1.1 Connector on port 443 -- Connector port=443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=2 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=10 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/server.ks keystorePass=tomcat / All the rest is default, and yes, I removed the comment !-- -- markers around this directive. In the catalina.2010-05-04.log file, I see the following output if I start the tomcat service: May 4, 2010 3:13:52 PM org.apache.catalina.core.AprLifecycleListener init INFO: Cannot find message associated with key aprListener.tcnValid May 4, 2010 3:13:52 PM org.apache.catalina.core.AprLifecycleListener init INFO: Cannot find message associated with key aprListener.flags May 4, 2010 3:13:52 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-80 May 4, 2010 3:13:52 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-443 May 4, 2010 3:13:52 PM org.apache.coyote.ajp.AjpAprProtocol init INFO: Initializing Coyote AJP/1.3 on ajp-8009 May 4, 2010 3:13:52 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 672 ms May 4, 2010 3:13:52 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina May 4, 2010 3:13:52 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.29 May 4, 2010 3:13:52 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled May 4, 2010 3:13:53 PM org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-80 May 4, 2010 3:13:53 PM org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-443 May 4, 2010 3:13:53 PM org.apache.coyote.ajp.AjpAprProtocol start INFO: Starting Coyote AJP/1.3 on ajp-8009 May 4, 2010 3:13:53 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource May 4, 2010 3:13:53 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 453 ms Changing the keystoreFile to bogus does not seem to provoke any error either. No other webserver or anything is listening on port 80 or 443. What am I missing? -- Mike 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: if user's browser doesn't support Cookies, then where to store user's session information?
There's an option somewhere to put the session ID into the URL. You can store state information in the session. Be careful, a browser with two windows will share the session between the two windows, so that a user may get very confusing results when you store currentpage in the session. Typically, the session is only used to store user login credentials, but not application data/state. You can store information on the client using hidden field on forms, which will send their data back when submitted. You can also add extra data in URLs, by adding parameters (e.g. href=nextpage?page=6queryid=10) or extra 'path' information (href=nextpage/10/6), which is very handy if you want to preserve user input across many links (any link will be relative to the URL that was used to reach this page, so ../7 could refer to page 7 of the same query). You can safely store a few kB of information in hidden fields or URLs without affecting performance. M. -Original Message- From: Peter Chen [mailto:peter.c...@aicent.com] Sent: dinsdag 12 januari 2010 10:01 To: users@tomcat.apache.org Subject: if user's browser doesn't support Cookies, then where to store user's session information? Hi, all I am using Tomcat 5.5.26 as the Web Server. I know the session information is stored in Cookies with the key JSESSIONID. But some browsers don't support Cookies. So my question is if user's browser doesn't support Cookies, then where to store user's session information? And besides session, how to store other user's state information, because HTTP protocol is a stateless protocol? Thanks. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: about the version of HTTP protocol
I want to know does this Tomcat support HTTP/1.0 or HTTP/0.9 protocol. Pleas help me make sure of it. I think the version of used HTTP protocol is determined by browser, is it right? Tomcat still supports the older protocols. The browser determines the version. Browsers have moved to 1.1 for decades, and were using extensions to 1.0 that became standard in 1.1 for years before that. So don't worry about the HTTP version. The only case I know that may cause problems for 1.0 clients is when you use virtual hosting. The host header is mandatory in 1.1, but was optional in 1.0. Without the host header, the server must make a guess as to what virtual host was intended, or you have to implement another means of directing users to the correct application. M. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to change effective user id on Windows
The current configuration is correct in terms of security - the 'SYSTEM' user is a limited account that has no access to the desktop nor shared network resources. Be warned that running a service under other credentials than the system user is likely to lead to a less secure configuration, instead of improving. M. -Original Message- From: Amit Agarwal [mailto:ami@gmail.com] Sent: donderdag 07 januari 2010 15:08 To: users@tomcat.apache.org Subject: How to change effective user id on Windows Tomat on Linux starts as root to bind to port 80, and then switches effective user id to nobody. Windows does not appear to have concept of changing effective user. Tomcat service runs as a local system on Windows. Need to change the user for Tomcat after binding to port 80. How can this be achieved? -- Sent from Karnataka, India 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Toggling
Just redirect as required. http://myserver/login redirects to https://myserver/login, form submits to the same page and when OK, it redirects to http://myserver/home or whatever. You'll probably need to pass a 'secret' to the home link to preserve the user's login, which might be a simple URI parameter. Don't do the above on the big bad internet. From a security perspective it's virtually pointless to do it this way. I'm assuming you're doing this because you have an intranet www server and some company policy dictates that plaintext passwords are not allowed on the net any longer. It's probably much smarter to look at single-sign-on solutions instead, Kerberos integration with Tomcat is about a day's work and will both provide a better user experience and provide much better security too. M -Original Message- From: Nikita Manohar [mailto:nikita.mano...@gmail.com] Sent: woensdag 06 januari 2010 10:17 To: Tomcat Users List Subject: Re: Toggling Hi Peter, The trigger here is suppose in a web application there is a welcome page which is to be re-directed to a user's homepage after login. The secure information (login page) should be toggled to https and the rest as http. Is it possible to do so automatically? Thank you, -Nikita 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: RE: Ignore http header if-modified-since
This header is invalid: Last-Modified: Do, 17 Dez 2009 11:11:29 GMT This is not according to spec, Dez should be Dec. Maybe tomcat chokes on it. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: donderdag 17 december 2009 12:26 To: users Subject: AW: RE: Ignore http header if-modified-since Hallo, unfortunately it is a 404. And the 404 is only delivered when the request header contains if-modified-since. If not the request is respondec correctly. This behaviour is reproducable. Below you find an example of failed and successful request. The GET URL is in both cases http://localhost:8080/mywebapp/faces/static/META-INF/progressb ar/script.js -- Failed Request (means tomcat responds with 404): Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 If-Modified-Since: Do, 17 Dez 2009 11:11:29 GMT Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1093 Date: Thu, 17 Dec 2009 11:24:38 GMT -- Successful: Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Last-Modified: Do, 17 Dez 2009 11:11:29 GMT Content-Type: text/javascript Transfer-Encoding: chunked Date: Thu, 17 Dec 2009 11:24:53 GMT Does anybody have an explanation for this? Best regards, Abid -Ursprüngliche Nachricht- Von: Looijmans, Mike [mailto:mike.looijm...@oce.com] Gesendet: Mittwoch, 16. Dezember 2009 15:48 An: Tomcat Users List Betreff: RE: Ignore http header if-modified-since I assume you mean 304 (Not modified) instead of 404 (Not found). Simplest I can think of is to NOT put the last-modified header in your response. Then the browser won't send you an if-modified-since back. On the other hand, if you can put a datestamp on the response - e.g. a file date or by reading it from a DB or so - provide the proper response and you get client-side caching for (almost) free, which can seriously reduce load on a server. M. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: woensdag 16 december 2009 14:11 To: users Subject: Ignore http header if-modified-since Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid (EOF) 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. - 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 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
RE: Re: AW: RE: RE: Ignore http header if-modified-since
The Last-Modified header is helping your server a lot, so don't just remove it. It allows the client to cache the contents reliably, and only update the cache when the server reports that the contents have changed. For dynamically generated content, such as servlet data, Tomcat will not append the Last-Modified by itself, because it does not know whether the data can be cached. For 'static' content such as files (javascript, images, static html), Tomcat will use the files' modified date/time stamp as a reference. I usually do the opposite as what you are requesting and go through lenghts to create a good last-modified for my dynamic data, so that the client can cache the contents and I can relieve the stress on the database backend. So in short, no, don't mess with it. M -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: donderdag 17 december 2009 18:08 To: users Subject: AW: Re: AW: RE: RE: Ignore http header if-modified-since I used the startup parameters -Duser.language=en -Duser.region=US This caused Tomcat to deliver the Last-Modified in the correct format. That solved the problem, no 404 anymore, thanks. So it seems to be a bug in tomcat...? Again my other question: How can I instruct tomcat not to put the Last-Modified Header into the response at all? Do I have to use a filter or can it be done by configuration? Or is is somehow not recommended fiddle with the headers? Best regards, Abid -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 17. Dezember 2009 15:59 An: Tomcat Users List Betreff: Re: AW: RE: RE: Ignore http header if-modified-since Abid Hussain wrote: Hi, this is interesting. As you see in my example (i put it again below), tomcat itself delivers the Last-Modified (Do, 17 Dez 2009 11:11:29 GMT) in a different locale (german) as the Date Header (Thu, 17 Dec 2009 11:24:53 GMT). That sounds to me like a bug. Maybe the easiest fix is to set an eglish-language locale when you start Tomcat. If this is under Linux, try the following : - open a console window on the server and enter locale -a this will give you a list of installed locales. Maybe do locale -a | grep en_ to limit the list. Then, pick one of the list that contains utf8 and en, like maybe en_us.utf8 Then, in the tomcat bin directory, find the script setenv.sh, or create it if it does not exist, and add a line : export LANG=en_us.utf8 The restart Tomcat and try again. Do the headers now look different ? 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: Re: AW: RE: RE: Ignore http header if-modified-since
In the days that I was forced to write my own HTTP server
implementation, I totally avoided Locale functions, to avoid this
particular type of problems. It's safer to create a few string arrays
with the proper (english) values and use those for day/month names.
Actually, I think the HTTP spec is silly - it should have used
-MM-DDTHH:MM:SS like RFC3339, not this weird format intended for us
meek humans.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: donderdag 17 december 2009 22:18
To: Tomcat Users List
Subject: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Abid,
On 12/17/2009 12:08 PM, Abid Hussain wrote:
I used the startup parameters
-Duser.language=en
-Duser.region=US
This caused Tomcat to deliver the Last-Modified in the
correct format.
That solved the problem, no 404 anymore, thanks.
So it seems to be a bug in tomcat...?
I would say so.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
Tomcat's behavior seems to ignore the specification, here.
Would you care to share your Tomcat version with us?
Looking at the DefaultServlet, it looks like it ultimately
uses
org.apache.naming.resources.ResourceAttributes.getLastModifiedHttp(),
which explicitly uses a US locale, though it doesn't specify en_US:
/**
* HTTP date format.
*/
protected static final SimpleDateFormat format =
new SimpleDateFormat(EEE, dd MMM HH:mm:ss zzz,
Locale.US);
...
/**
* @return Returns the lastModifiedHttp.
*/
public String getLastModifiedHttp() {
if (lastModifiedHttp != null)
return lastModifiedHttp;
Date modifiedDate = getLastModifiedDate();
if (modifiedDate == null) {
modifiedDate = getCreationDate();
}
if (modifiedDate == null) {
modifiedDate = new Date();
}
synchronized (format) {
lastModifiedHttp = format.format(modifiedDate);
}
return lastModifiedHttp;
}
Locale.US yields en_US on my system (LC_CTYPE=en_US.UTF-8).
I tried messing with LC_TYPE and I see that:
$ LC_CTYPE=en_US java LocaleTest
Locale.default = en_US
Locale.US = en_US
$ LC_CTYPE=de_DE java LocaleTest
Locale.default = de_DE
Locale.US = en_US
So, it looks like Locale.US always means en_US, though it
wouldn't hurt to be explicit about the language, here.
If Response.setDateHeader is called, you get this:
public void setDateHeader(String name, long value) {
if (isCommitted())
return;
// Ignore any call from an included servlet
if (included) {
return;
}
if (format == null) {
format = new
SimpleDateFormat(DateTool.HTTP_RESPONSE_DATE_HEADER,
Locale.US);
format.setTimeZone(TimeZone.getTimeZone(GMT));
}
setHeader(name, FastHttpDateFormat.formatDate(value, format));
}
So, it looks like Tomcat 6.0.20 does things properly, at
least when it comes to DefaultServlet and
Response.setDateFormat. Oddly enough, these SimpleDateFormat
objects are being created all the time even though the
Response object is not guaranteed to be threadsafe... why not
simply re-use the DateFormat object forever since it's always
the same thing?
Are you sure that this date header is coming from Tomcat's code?
Again my other question: How can I instruct tomcat not to put the
Last-Modified Header into the response at all? Do I have to use a
filter or can it be done by configuration? Or is is somehow not
recommended fiddle with the headers?
It doesn't look like DefaultServlet has any options for this,
so you'll have to do it with a filter or valve. If it's
really Tomcat's code that is the problem, you almost
certainly will need a Valve since the code might not be
wrappable via a filter. I think it would be most interesting
to see where that header is being set... I suspect this code
hasn't changed for quite a while.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksqn/YACgkQ9CaO5/Lv0PBbeQCfYlW2uiVT4j0T1QMF+MLwVjLX
EpkAmwf3lUMQZc6ikfVA64r8w9PD3jAk
=vIOz
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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
RE: Ignore http header if-modified-since
I assume you mean 304 (Not modified) instead of 404 (Not found). Simplest I can think of is to NOT put the last-modified header in your response. Then the browser won't send you an if-modified-since back. On the other hand, if you can put a datestamp on the response - e.g. a file date or by reading it from a DB or so - provide the proper response and you get client-side caching for (almost) free, which can seriously reduce load on a server. M. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: woensdag 16 december 2009 14:11 To: users Subject: Ignore http header if-modified-since Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid (EOF) 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: About the http requests cache of Tomcat 5.5.26
I am watching the log of Tomcat. I found after 20 minutes, the Tomcat still create lots of new sessions. But the LoadRunner has stopped to send request for 15 minutes. Makes perfect sense to me. The servlet times out on the DB connection, which may take up to a minute or so, fails, and then processes the next request, which will experience the same timeout. Since you have somehow asked for sessions to be created for each, tomcat will still be processing requests and thus creating sessions. Your caching thing happens at the socket level. This pseudocode application runs on any single system, without blocking or deadlocking: #server s = socket(..) s.listen() # Client - this will not block c = socket(..) c.connect(s.getaddr()) c.send(hello) c.close() # server again - no, we're not using threading m = s.accept() data = m.recv() m.close() In other words, you can connect, send and close a client socket, without the server actually ever reading the request. If you set the SO_LINGER option in the client, or simply wait for the response, you can alter this behaviour. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: the Tomcat generates more than one session id with the same http request, please help me
The reason is that other browsers use a media player component that reconnects to the server. The session is linked to the browser instance. As a result, the session is lost when the mediaplayer connects to get the audio data. Whap happens in other browsers is the equivalent of storing a bookmark, closing the browser, starting a new browser and retrieving the bookmark. This will not work in your application because you depend on the session to remain the same. The solution is to either NOT depend on the session for the audio data retrieval, OR to include the session ID in the url itself. Which solution you choose and how you wish to implement that solution is entirely up to you. We'll be glad to help you regardless oft he implementation you pick. Just don't expect your application to function without modification, it is not Tomcat's nor the browser's fault that it does not work, it is something you need to address in your web application. M. But if I change to use IE6/IE7/IE8, this problem never happened. Does someone know the reason? thanks. 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: the Tomcat generates more than one session id with the same http request, please help me
Put the session ID in the URL and it will work on all systems. Alternatively, don't use sessions for the audio file. -Original Message- From: Peter Chen [mailto:peter.c...@aicent.com] Sent: maandag 07 december 2009 09:22 To: users@tomcat.apache.org Subject: the Tomcat generates more than one session id with the same http request, please help me Hi, all I am testing a website with the server Tomcat. I am using Tomcat 5.5.26, and I found one problem. The website is used to display audio files. After I log in the website, I can see the icon of the audio file. But after I press the button play, it has different results with different browsers. When I use firefox3.5.5 and Google Chrome 3.0, I found the Tomcat will create more than one session id, and it can not be played. But if I use IE6.0/IE7.0/IE8.0, I found there is only one session id, and it plays well. I don't know the reason, has someone met this problem before, please help me to solve this problem, thanks. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: the Tomcat generates more than one session id with the same http request, please help me
Seems like a propietary way of storing the session ID, I'm not much into JSP
stuff so I really don't know. Someone else here may be able to explain.
You can store whatever you need in parameters, either by putting into URLs or
by creating (hidden) controls on web forms. This is the preferred method of
parameter passing, as it allows multiple instances (e.g. browser tabs) to
coexist. You should only store things in a session that are related to the
connection and user (e.g. user credentials, preferences and such), but
absolutely not the page he's navigating now.
You can also add a path to the URL, e.g.
getparts.jsp/137063/4
Then getPathInfo() will return 137063/4 in getparts.jsp.
M
-Original Message-
From: Peter Chen [mailto:peter.c...@aicent.com]
Sent: dinsdag 08 december 2009 07:49
To: Tomcat Users List
Subject: RE: the Tomcat generates more than one session id
with the same http request, please help me
Thanks for Mike's reply.
I searched on the Internet, and I got a method, the detail is
as follows:
script language=JavaScript
document.write('object width=320 height=45
classid=CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95');
document.write('param name=filename
value=getParts.jsp;jsessionid=B01FF12CBC92F9BA1682E9A883A3A1A
D?timestamp=1260252638867contentid=137063timemark=20091110i
ndex=4 /');
document.write('PARAM NAME=AUTOSTART value=false');
document.write('embed width=320 height=45
type=application/x-mplayer2
src=getParts.jsp;jsessionid=B01FF12CBC92F9BA1682E9A883A3A1AD?
timestamp=1260252638867contentid=137063timemark=20091110ind
ex=4 AutoStart=0');
document.write('/embed');
document.write('/object');
/script
The most important sentence is
getParts.jsp;jsessionid=B01FF12CBC92F9BA1682E9A883A3A1AD?time
stamp=1260252638867contentid=137063timemark=20091110index=4
I know the URL like
getParts.jsp?timestamp=1260252638867contentid=137063timemar
k=20091110index=4, this URL is used to pass parameters from
one Jsp to another one. And we can get parameters with
sentences like request.getParameter(timestamp);
request.getParameter(contentid ).
But I don't know the part
getParts.jsp;jsessionid=B01FF12CBC92F9BA1682E9A883A3A1AD,
is it also used to pass parameter?
If so, how to get the parameter? Thanks.
-Original Message-
From: Looijmans, Mike [mailto:mike.looijm...@oce.com]
Sent: 2009年12月7日 16:39
To: Tomcat Users List
Subject: RE: the Tomcat generates more than one session id
with the same http request, please help me
Put the session ID in the URL and it will work on all systems.
Alternatively, don't use sessions for the audio file.
-Original Message-
From: Peter Chen [mailto:peter.c...@aicent.com]
Sent: maandag 07 december 2009 09:22
To: users@tomcat.apache.org
Subject: the Tomcat generates more than one session id with
the same
http request, please help me
Hi, all
I am testing a website with the server Tomcat. I am using Tomcat
5.5.26, and I found one problem.
The website is used to display audio files. After I log in the
website, I can see the icon of the audio file. But after I
press the
button play, it has different results with different browsers.
When I use firefox3.5.5 and Google Chrome 3.0, I found the
Tomcat will
create more than one session id, and it can not be played.
But if I use IE6.0/IE7.0/IE8.0, I found there is only one
session id,
and it plays well.
I don't know the reason, has someone met this problem
before, please
help me to solve this problem, thanks.
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.
-
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
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
RE: Tomcat Crashes out of continuous servicing of stuck request
... Without trying to send something back to the client, there is no way telling the client closed the window (or pressed reload or switched to another URL). I would expect the socket to be closed, which can be detected at the server side. The exceptions I can think of are the client crashing or a network disconnect. Though apache probably detects the socket's close, it has little means of informing the associated servlet because that is blocked waiting for the response from the database. Depending on the database, it is usually also no use to try and stop - the query will continue its work even though the requesting user is gone on most DBMSes. So taking a slot in the webserver is not a big issue, the DB is wasting far more resources on that user. Other options to explore are dividing the big query into multiple smaller ones, so that you can abort sooner. Use INTO TEMP to store intermediates. That would give you the opportiunity to check whether the client is still listening - and you could even give the client some updates on progress, which may be considered a nice to have feature as well. Best of all would be to optimize the database and make those queries faster, but I guess you must have valid reasons for not doing so. M. -- My reply ends here -- 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Crashes out of continuous servicing of stuck request
Just an idea: What happens if you change your DB call into a Sleep(30) or something similar? Does tomcat still misbehave then? (the 'retry' could be related to something else than tomcat). M -Original Message- From: Hadole, Nishant IN BOM SISL [mailto:nishant.had...@siemens.com] Sent: vrijdag 04 december 2009 11:06 To: 'Rainer Jung'; Tomcat Users List Subject: RE: Tomcat Crashes out of continuous servicing of stuck request Dear Rainer, Thanks for explanation. In this particular case, when client press a button on JSP, it initiates a Database search operation, which may take time up to 30-45 seconds. Meanwhile, we are showing a screen which tell user that his / her request is being processed and no to close the window. But, sometimes users are impatient and still close the window. Yes, as you suggested, it is possible to handle close event / stop processing by some notification, but application is full of such utilities, and it is too much of efforts. I am interested in some parameterization, which detects broken connection and automatically drops stuck request. I have even checked this with requests with STAGE as KEEPALIVE, but not working with STAGE as SERVICE. Also, I am not able to figure out, why the processing is repeated. With best regards, Nishant Hadole Mailto: nishant.had...@siemens.com 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Safe to move tomcat directory while tomcat running?
On unix (posix, linux) systems you can move anything even when in use. Files that are open will remain open, and the application will continue to use them. Problems will arise when the application attempts to open new files, because then they have to be at the expected location. If you really want zero downtime, you can set up softlinks to make the program believe that everything is still in its old location during the transition phase. On the other hand, if you prepare it well, you can stop, move and start in a matter of seconds, and most users will never notice it was down. And the risk of the whole thing crashing down because of some peculiarity in the application due to the unexpected move is probably big enough to want to avoid that situation. M. -Original Message- From: Dean Chester [mailto:dean.g.ches...@googlemail.com] Sent: dinsdag 01 december 2009 22:08 To: Tomcat Users List Subject: Re: Safe to move tomcat directory while tomcat running? I would be doing it on red hat. Would it just be easier to email all the users and say its down for maintenance and then just move it? Dean On Tue, Dec 1, 2009 at 9:02 PM, David kerber dcker...@verizon.net wrote: Dean Chester wrote: Hi, I have to move the tomcat directory with in my user and i ask is it safe if i do it while tomcat is running as i need to avoid downtime of my application. Thanks in Advance Dean I doubt you would even be able to do so, at least not in Windows. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP with HTTPD - Buffer Size on long URLs
The RFC specs a maximum URL size of 4k. That should be enough for everybody. Note that you can mix and match as required: Use the URL portion of your request to identify the target of the request, and put the additional data in the POST body. -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: zaterdag 28 november 2009 13:11 To: Tomcat Users List Subject: Re: AJP with HTTPD - Buffer Size on long URLs Nilesh Bansal wrote: Using ProxyIOBufferSize as 32192 totally worked even though the documentation suggests otherwise. I am using httpd 2.2.14 with Tomcat 6.0.16. Thank you for the tip, now I can again use my long urls. This may work for now, but someone should tell you that sending large amounts of data in a HTTP GET request is not such a good idea. It will get you in trouble sooner or later, for various reasons. You should use a POST request for that kind of thing. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP with HTTPD - Buffer Size on long URLs
Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, ... Has anyone met this problem? Please give me some advice, thanks in advance. Well, it seem that you are running out of memory. That, or the underlying VM implementation just throws that exception because it's close enough to the real problem. So the OS reports sorry, there's plenty memory but I cannot start your thread because that would allocate some other resource that is running out, and the VM translates this to OutOfMemoryError because a SorryICannotStartYourThreadError isn't defined. Much like running out of GDI resources in an AWT application would throw OutOfMemoryError, simply because the Java VM cannot translate the information from the OS because in the Java world, these things don't exist. M. disclaimer: My message ends here 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP with HTTPD - Buffer Size on long URLs
I stand corrected. What I do recall is that in the 1999's I was forced to build an HTTP/1.1 server from scratch (in objective-C) and, when faced with the question at what point in reading the URI should I give up and decide this is not a HTTP request?, I found 4k to be the 'correct' answer. Since RFC2068 was the basis for that server, I was lazy and assumef that that's where it originated. Anyway, when creating arbitrary long URIs, you can be sure that at some point any HTTP server will give up, because it is more or less forced to store the URI in precious RAM. Probably the 4k limit was intended as the maximum size you can expect a HTTP server to accept, anything beyond that is at your own peril. The SHOULD return 414 is easily explained: If it stops reading the URL, it has no knowledge of the client's intended protocol yet, it is not aware of the other headers in the request, and as such the server may not be able to determine whether the client really expects a HTTP response at all. So the safe thing to do is just close the connection and give up. Having said that, there is a very clear distinction between GET and POST requests. The main difference is that POST requests in general have a side-effect, and cannot be expected to return the same result twice. For example, POST /mything might return created a file the first time, and file already exists the second time. M. !-- -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: maandag 30 november 2009 15:54 To: Tomcat Users List Subject: RE: AJP with HTTPD - Buffer Size on long URLs From: Looijmans, Mike [mailto:mike.looijm...@oce.com] Subject: RE: AJP with HTTPD - Buffer Size on long URLs Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) Citing an obsoleted RFC is a bit odd. Regardless, the actual wording from section 3.2.1 of 2068 and 2616 (the superseding document) is: The HTTP protocol does not place any a priori limit on the length of a URI. Followed shortly by: A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). (Note the SHOULD, not MUST.) There is also a warning note: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. No mention of a 4K limit anywhere that I can find. - Chuck 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
Let's refresh the issue : A request comes into Tomcat for a URL /. It comes in either on port 80 or port 666. And you want it to be processed by the webapp at /myapp/. No: If it comes in at port 80, nothing different is supposed to happen. So / should do whatever / would always do. Yes: If it comes in on 666, I want it to behave as if it called for /myapp/ So you need 2 Connectors : Connector port=80... Connector port=666 .. Tomcat passes the request to the same Host .. anyway, which has a top location for webapps, probably (tomcat-dir)/webapps/. Tomcat will try to match the / request to a webapp located at (tomcat-dir)/webapps/. So you would need a webapp there, even if it is a dummy, just so that you have a place to put your filter and its (tomcat-dir)/webapps//WEB-INF/web.xml configuration file, and its classes or jars. In that web.xml, you will tell Tomcat that around the dummy webapp, there is a filter, and that it should handle all request URLs starting with /. What the filter does then is up to you. I think that urlrewrite would be able to re-direct this call to the webapp at /myapp/, just by a couple of configuration lines. That will NOT work then. Because the is a random word, not a constant, nor the name of a servlet. Think wikipedia, the request might be for /foo or /bar or whatever, and the servlet uses that word for its own purposes (it will look it up in the database and return something interesting). M. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
I think so too. My personal doubt is still about how Tomcat
would try map a request that comes in as /,
being variable and being NOT myapp. Since it does not find
a match with /myapp, and since obviously there cannot be an
infinity of /webapps/ apps pre-configured, would it
then pass it to the default app (/ROOT) ?
I tried this route, and the results are quite remarkable.
When I deploy the webapp as ROOT.war, it gets to serve all requests that
don't match anything else. So if the webapps dir looks like this:
/ROOT.war
/SomeApp/*
/OtherApp.war
When I send a request for /SomeApp/something, it goes to the webapp in
that folder, likewise a request for /OtherApp/something ends up in the
OtherApp servlet.
A request for /foo or /bar, which does not match anything in the folder,
gets sent to the ROOT.
With this mechanism, I could program the ROOT as (in pseudocode):
if port == 666:
handle(pathinfo)
else if pathinfo.startwith('/MyApp'):
handle(pathinfo.split('/',2)[1])
else:
error(404)
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.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Redirecting a port to a webapp
Hello, After hours of googling and browsing documentation, i came to the conclusion that what i want is either so trivial that everybody knows how to do it, or so complicated that no one ever tried it... I want to accomplish the following in Tomcat 5.5: http://myserver:80/xxx just does whatever it always does. http://myserver:666/xxx is equivalent to http://myserver:80/myapp/xxx So i want all requests targetted at a particular port (666) in this case to be forwarded to a particular servlet, which is also served under its own subdirectory on the regular HTTP port 80. I can set up a connector at port 666 and have all its request go somewhere else, but then the application cannot be reached through the normal port (80), which is crucial for this thing to work. Installing two copies will accomplish that, but then the two copies live in different universes and cannot communicate - and setting up some IPC between them is overkill i'd say. Mike Looijmans Océ-technologies http://www.oce.com/ | Topic automation http://www.topic.nl/ 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: Redirecting a port to a webapp
... Note that you'll end up with two independent copies of the servlet in your two webapp directories, and they won't share things like Sessions between them. And, as I mentioned, I don't want that to happen. You might, however, be able to get what you want using a combination of http://tuckey.org/urlrewrite/ and two Connectors defined on the same Service. Instead of introducing a third party component, it seems possible to write a custom Filter to do this. All it needs to do is look at the incoming port and if that equals 666 insert the /myapp into the url? The documentation on Filters is large but provides - again - little examples (like how to explain to Tomcat that I want to use this filter...). Anyway, I prefer any solution that stays within Tomcat. Mike. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
Because you want different sets of webapps served on your different connectors, I *think* you'll need two different Services in your server.xml: Server Service for port 80 Connector for port 80 Engine for port 80 Host for port 80, specifying base directory for your port 80 webapps /Engine for port 80 /Service for port 80 Service for port 666 Connector for port 666 Engine for port 666 Host for port 666, specifying base directory for your port 666 webapps /Engine for port 666 /Service for port 666 /Server The fastest way to make such a configuration will be to edit your existing server.xml, copy+paste the Service.../Service section (which is most of the file) and hack at the copy as necessary. I tried this, just to be able to make some progress on the actual project, but it does not work as expected. I copied the server part and replaced: Host name=localhost appBase=webapps / with Host name=localhost appBase=webapps/myapp / And changed the connector to use port 666. The result is that when I browse to http://localhost:666/ I get a blank page. No error message, just nothing. If I change the Host thing to read: Host name=localhost appBase=webapps/aDirThatDoesNotExistAtAll / I get the same result: Silently nothing. If I revert the Host part by removing the subdir, I can acess http://localhost:666/myapp just fine. Duh? Mike. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
I tried this, just to be able to make some progress on the actual project, but it does not work as expected. I copied theserver part and replaced: Host name=localhost appBase=webapps / with Host name=localhost appBase=webapps/myapp / You're telling the Host to look for war files or exploded app directories in webapps/myapp. Yes I do. Isn't that what I want then? I want http://localhost/myapp/ and http://localhost:666/ to mean the same, so just moving the webapps root a level deeper seems the logical thing to do. Instead, set it to webapps2 or a similar existing directory and place the web app inside that directory. /path/to/tomcat/webapps /path/to/tomcat/webapps/ROOT /path/to/tomcat/webapps/myapp /path/to/tomcat/webapps2/ROOT /path/to/tomcat/webapps2/otherapp If I understand your suggestion correctly, that would make http://localhost/myapp/ and http://localhost:666/otherapp/ equivalent - not what I want - and it requires me to install two copies of the servlet in different locations? Mike. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
Some additional information: The blank page is actually a 400 Bad Request response. A 404 I could understand - especially when the directoy does not exist - but why it returns 400 is a total mystery. There's nothing in the log files, the access log just mentions the 400 response. There is also nothing in the response or its headers to further explain what's wrong with the request. Mike. -Original Message- From: Looijmans, Mike Sent: maandag 23 november 2009 14:06 To: Tomcat Users List Subject: RE: Redirecting a port to a webapp Because you want different sets of webapps served on your different connectors, I *think* you'll need two different Services in your server.xml: Server Service for port 80 Connector for port 80 Engine for port 80 Host for port 80, specifying base directory for your port 80 webapps /Engine for port 80 /Service for port 80 Service for port 666 Connector for port 666 Engine for port 666 Host for port 666, specifying base directory for your port 666 webapps /Engine for port 666 /Service for port 666 /Server The fastest way to make such a configuration will be to edit your existing server.xml, copy+paste the Service.../Service section (which is most of the file) and hack at the copy as necessary. I tried this, just to be able to make some progress on the actual project, but it does not work as expected. I copied the server part and replaced: Host name=localhost appBase=webapps / with Host name=localhost appBase=webapps/myapp / And changed the connector to use port 666. The result is that when I browse to http://localhost:666/ I get a blank page. No error message, just nothing. If I change the Host thing to read: Host name=localhost appBase=webapps/aDirThatDoesNotExistAtAll / I get the same result: Silently nothing. If I revert the Host part by removing the subdir, I can acess http://localhost:666/myapp just fine. Duh? 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Redirecting a port to a webapp
No. You want webapps/myapp to be treated as the ROOT context for a host. appBase=webapps/myapp means look in the webapps/myapp directory to find contexts for this host. The ROOT context in that case would be webapps/myapp/ROOT As a general rule any configuration that boils down to docBase== (which is the same as appBase==docBase) is not going to behave they way you want it to. Since I don't understand a bit of this reply, I'll interpret it as please go read the manual... I want http://localhost/myapp/ and http://localhost:666/ to mean the same, so just moving the webapps root a level deeper seems the logical thing to do. That would be logical if the file system mapped directly to the web URL space but it doesn't. Probably the word apache has lead me into believing that tomcat would behave like other webservers: Just point it to some root location and then it will follow the filesystem. ... If you follow that route yes. Another option would be to put the webapp somewhere outside of any host's appBase and then you can use context.xml files under CATALINA_BASE/engine name/host name to add the webapp to as many hosts as you like. Needless to say, I again have no idea what you're talking about... back to reading the documentation again... Mike. 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
