Re: Session timeouts: ignore "periodic polling" URL?

[sebb]

On 20 March 2011 11:19, André Warnier  wrote:
> sol myr wrote:
>>
>> Hi,
>>
>> We have a Servelts/JSP application Tomcat6.
>> Our javascripts issues automatic, periodic polling requests (Ajax and
>> Comet), in order to keep the view  up-to-date.
>> Unfortunately this prevents sessions from timing out...
>>
>> Is there a way to tell Tomcat that some URL shouldn't affect session
>> timeouts?
>> Namely if for the last 30 minutes, the browser requested nothing but
>> "http://server/autoRefresh.do"; , then Tomcat should assume the user went
>> away from the computer, and kill the session.
>>
> You may have to explain the logic of this a bit better, because on the face
> of it, it makes no sense.
> Presumably, if you create a session, it is because the application needs a
> session (aka, needs some information to be preserved between individual
> requests of the same user/browser).
> Then why would you want it to time out ?

This is the sort of behaviour one wants for online banking - the
session should be logged out if the user does not do anything for a
while, even though the page may be doing background requests.

> And if you don't need a session, then why do you create one ?

> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Caching Problem

[sebb]

On 29 March 2011 21:47, Jinal Dhruv  wrote:
> I dont understand second option..Can U explain a bit more?

In case you cannot access the cited document:

http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Common%20Attributes

it says:

"reloadable 

Set to true if you want Catalina to monitor classes in
/WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically
reload the web application if a change is detected. This feature is
very useful during application development, but it requires
significant runtime overhead and is not recommended for use on
deployed production applications. That's why the default setting for
this attribute is false. You can use the Manager web application,
however, to trigger reloads of deployed applications on demand."

>
>
> 
> From: Christopher Schultz 
> To: Tomcat Users List 
> Sent: Wednesday, 30 March 2011 2:07 AM
> Subject: Re: Tomcat Caching Problem
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jinal,
>
> On 3/29/2011 4:01 PM, Jinal Dhruv wrote:
>> I want Tomcat to stop catching my servlet responses and I cant understand 
>> the solution at
>> http://stackoverflow.com/questions/415520/how-do-i-make-tomcat-stop-caching-my-servlet-responses
>
> That's because the proposed solution isn't one.
>
> Here are your options:
>
>
> 1. Use the manager to reload the web app (undeploy/redeploy should not
> be necessary: a simple reload should work) (
> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Reload_An_Existing_Application
> )
>
> 2. Set the element in META-INF/context.xml to have reloadable="true" (
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html )
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2SQu8ACgkQ9CaO5/Lv0PASiACdFViaKOGVUSQnOn0nM1cDOy/q
> bfQAoJFklSKNwedSAfMoJXhnBKqzAG2o
> =/jWG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Protecting against HTTP response splitting

[sebb]

On 1 April 2011 15:49, Christopher Schultz  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ronald,
>
> On 3/31/2011 8:21 PM, Christopher Schultz wrote:
>> On 3/31/2011 7:05 AM, Ronald Klop wrote:
>>> I would say that some proper input validation solves your problem.
>>> Does new URL(redirectURL).toString() give an exception on invalid url's?
>>
>> new URL(String) will throw a MalformedURLException if there are illegal
>> characters in the URL.
>>
>> I suppose that's good enough for my purposes: the only returnURLs that
>> should be generated should be coming from our own application, and if
>> they are broken, it's a bug. If a MalformedURLException is thrown, it
>> should be due to some sort of malicious use and the user is better off
>> getting a nasty error than just about anything else.
>
> Apparently, it's more complicated than that... at least when it comes to
> my particular application... we want to keep the URLs as short as
> possible, they they are not fully-qualified in most cases. Instead, they
> are webapp-relative and blindly passing them into the java.net.URL
> constructor fails even for "real" URLs because they have no protocol.

I may be missing something here, but can't you use the ctor:

URL(URL context, String spec)

and pass in a dummy context with a suitable protocol?

> Now, I could add code to fully-qualify them, but then I'd be doing work
> I'm already asking the container to do for me (since
> HttpServletResponse.sendRedirect is required to fully-qualify the URL
> anyway) and I'd prefer to rely on the container for that task -- it's
> likely to do a better job, anyway :)
>
> I think I'm doing to standardize on simply scanning for troublesome
> characters like \r and \n and throwing a MalformedURLException or
> something like that.
>
> If anyone else has any good ideas or Warnings about what might be a
> naive sanitization check, I'd be glad to hear them.
>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2V5gsACgkQ9CaO5/Lv0PBgfwCeOrioFeSvp8iUJ51a9qJqAny3
> 8QkAn0c12aRinn7eoGUoAgA2uYydVQA/
> =bwLF
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: linux users who unload from zip file can't start tomcat

[sebb]

On 2 April 2011 10:35, Robert P. J. Day  wrote:
>
>  i just noticed that users on a linux/unix system that unload tomcat7
> from the zip file are going to have trouble running it since the bin/
> scripts are not marked executable in the zip file.

Unfortunately Zip does not support such attributes.

>  if tomcat7 is unloaded from the tar ball, then everything will work
> fine since the scripts are executable.  but from the zip file, they
> aren't, which means someone who runs "sh bin/startup.sh" will get:
>
>  Cannot find bin/catalina.sh
>  This file is needed to run this program
>
> and that's because of this test in startup.sh:
>
>  if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then
>    echo "Cannot find $PRGDIR/$EXECUTABLE"
>    echo "This file is needed to run this program"
>    exit 1
>  fi
>
> the catalina.sh script is there, of course, it's just not executable
> so startup.sh (misleadingly) claims it doesn't exist.

 Agreed, the message is misleading.

>  experienced linux users will probably notice what's going on
> immediately, but others might be thoroughly confused.
>
> rday
>
> --
>
> 
> Robert P. J. Day                               Waterloo, Ontario, CANADA
>                        http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] servlet-specific error pages

[sebb]

On 14 April 2011 01:10, Justin Randall  wrote:
>
> Hi Chris,
>
>> Of course. I was wondering about other exceptions or errors that maybe I
>> cannot control from that code.
>
> Are you referring to internal exceptions within Tomcat's own code or simply 
> unexpected exceptions within the servlet's implemented code?  If it's the 
> later you could always just wrap your code with a try block that catches 
> "Throwable" which will catch any possible exception thrown by Java and 
> properly implemented library exceptions.  Perhaps not ideal but considering 
> the available options it might not be too bad.
>
> Technically speaking, catching Throwable isn't such a bad practice for 
> end-user facing applications because you can at least redirect to a more 
> elegant "Unexpected Exception has occurred" page rather than an error page 
> showing a stack trace of a NullPointerException or some other unexpected 
> errors due to programming mistakes as an example.

Some Throwables should never be caught - or if they are, must be rethrown.
For example, ThreadDeath and VirtualMachineError.

Should be safe to catch RuntimeException (includes NPE) and Exception.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: storing images

[sebb]

If multiple threads try to create the image at the same time it is
possible that one thread will see a partial file - or the file may be
locked.

If you are not doing this already, I suggest creating the file with a
unique temporary name and then renaming it once complete.
The rename may fail if another thread has meanwhile created it, but
that can easily be allowed for.

Trying to lock the file whilst it is created is likely to be harder to
implement; however it might be worth it if the file creation is very
expensive in system resources.

On 6 May 2011 13:48, Thad Humphries  wrote:
> I'd store the image to java.io.tmpdir and retrieve it with a servlet. I
> doing this now with my Ajax application.
>
> On Thu, May 5, 2011 at 2:19 PM, alexis  wrote:
>
>> Hello all, im facing an issue, ive been testing for a while different
>> approaches without success.
>>
>> I have a servlet that basically does
>>
>> . creates an image
>> . store the image on disk
>> . returns an html  tag pointing to the stored image.
>>
>> reason why the servlet doesnt returns the image directly using a response
>> type image/png is the servlet is called from an ajax script, this ajax
>> script renders the inner text inside a div on a jsp page on the same context
>> that the server runs. ajax can only render html on divs, there's no way to
>> return binary content (the image) from the servlet to the ajax script.
>>
>>
>> So, i have to create the image on the servlet (done) , store the image on
>> the disk (done), and return the  tab also done. Thing is, where im able
>> to store the image from the servlet im not able to read it from the jsp.
>>
>> I tried with /tmp, i tried with servletcontext.getpath to store the file on
>> that dir, nothing seems to work. where should i store and reference those
>> images to be written by the servlet and read by the jsp?
>>
>> thanks in advance
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v, 121-24)
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader

[sebb]

On 13 May 2011 13:56, Jim Seymour  wrote:
> On Wed, 11 May 2011 18:04:15 -0400
> Jim Seymour  wrote:
>
>> On Thu, 12 May 2011 01:16:43 +0400
>> Konstantin Kolinko  wrote:
>>
>> > 1) jsvc is not developed within Apache Tomcat project but within
>> > the Apache Commons - it belongs to Apache Commons Daemon, -- your
>> > question belongs there
>> > http://commons.apache.org/daemon/
>>
>> Thanks!  I'll subscribe there and re-post.
> [snip]
>
> Well, Konstantin, there was no joy over there, either, so I guess
> I'll have to seek another solution.  Thanks for the pointer.

Or wait a bit longer - you only posted 2 days ago here.

> Regards,
> Jim
> --
> Note: My mail server employs *very* aggressive anti-spam
> filtering.  If you reply to this email and your email is
> rejected, please accept my apologies and let me know via my
> web form at .
>
> -
> 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

[OT?] Virtual hosting - does the port need to match the URL port?

[sebb]

HTTP requests include a "Host:" header which generally specifies the
target hostname and port (omitted if it is the default port).

AIUI, in virtual hosting situations, the name in the Host header may
be different from the URL host.
So for example a request to:

http://localhost:8080/

might be sent with the header:

Host: stimpy:8080

in order to direct the request to the "stimpy" virtual host.

Does it ever make sense for the "Host" port to be different from the
URL port? For example:

Host: stimpy:9090

As far as I can tell, Tomcat validates the format of the Host header,
but otherwise ignores the port?
Is that correct?

Does anyone know of other servers that make use of the Host port setting?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT?] Virtual hosting - does the port need to match the URL port?

[sebb]

On 17 May 2011 22:17, Konstantin Kolinko  wrote:
> 2011/5/18 sebb :
>> As far as I can tell, Tomcat validates the format of the Host header,
>> but otherwise ignores the port?
>> Is that correct?
>
> No.
> See e.g. Http11Processor.parseHost(MessageBytes) in trunk. The last
> line there is
> [[[
>  request.setServerPort(port);
> ]]]
> where port number in parsed from the header.

I see, so whatever code uses the request can use the port if it wants to.

But AFAICT Tomcat does not validate that the port matches the original
request - I tried sending it a nonsense port and the request worked.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT?] Virtual hosting - does the port need to match the URL port?

[sebb]

On 17 May 2011 23:35, André Warnier  wrote:
> sebb wrote:
>>
>> HTTP requests include a "Host:" header which generally specifies the
>> target hostname and port (omitted if it is the default port).
>
>> AIUI, in virtual hosting situations, the name in the Host header may
>> be different from the URL host.
>> So for example a request to:
>>
>> http://localhost:8080/
>>
>> might be sent with the header:
>>
>> Host: stimpy:8080
>>
>> in order to direct the request to the "stimpy" virtual host.
>>
>> Does it ever make sense for the "Host" port to be different from the
>> URL port? For example:
>>
>> Host: stimpy:9090
>>
>> As far as I can tell, Tomcat validates the format of the Host header,
>> but otherwise ignores the port?
>> Is that correct?
>>
>> Does anyone know of other servers that make use of the Host port setting?
>>
>
> With respect (and a willigness to help), I believe that you have a wrong
> understanding of the basics of how this all works, and as a consequence your
> questions and theories above are a bit off the mark (if not necessarily
> off-topic for this list).
>
>
> When you enter a URL in the URL box of the browser and hit , what
> happens is as follows.  Let's suppose that the URL in question is :
>
> http://someserver.company.com:8080/something?name1=value1
>
>
> 1) the browser splits the URL into several parts :
> - http://  (the "protocol" part)
> - someserver.company.com  (the hostname part)
> - (optionally) 8080 : (the port, which if not specified is "80" for HTTP)
> - the rest : /something?name1=value1
>  (which is itself conmposed of different parts, but that is not important
> here)
>
> 2) the browser takes the hostname part "someserver.company.com", and asks
> its local operating system to translate this to an IP address.  The part of
> the OS which does this is called the "resolver", and it makes use the DNS
> system in order to make this name-to-address translation.
>
> 3) when the browser has the IP address of the target server, it creates a
> TCP connection *to that IP address*, and to the explicit or implicit port.
> The result of this is that there is now a direct connection between the
> browser and that server, over TCP/IP.
> And on that server, this connection is handled by whichever process was
> listening on that port.  In general, for HTTP, this will be a webserver
> process (like Apache httpd or Tomcat).
>
> So what the browser writes to that connection, is read by the webserver, and
> vice-versa what the webserver writes to that connection, is received and
> read by the browser.
>
> 4) on this connection, the browser now writes a HTTP request.  That request
> is composed of several lines, of which there are at least the following 3
> lines :
> GET /something?name1=value1 HTTP/1.1
> Host: someserver.company.com
>
> (the empty line indicates the end of the request headers, which for a "GET"
> request is also the end of the request)
>
> Now we look at the webserver, which receives this request over the
> connection.
>
> 1) The server reads the request lines, and first looks at the "Host:" line.
> That tells it which "virtual server" (or "virtual host") the browser is
> trying to reach. In this case the browser, through that Host: header line,
> indicated that it is a virtual host named "someserver.company.com".
>
> 2) The webserver then checks in its configuration, if it really has a
> virtual host named that way.  For Tomcat, that would mean that in its
> "server.xml" file, there exists a tag like :
> .
>
> 2a) if there is no such virtual host, then the server will use its "default
> host" to process this request.  For Tomcat, that is the Host (also
> identified by a  tag, whose name is in the  tag, like :
> 
>
> 2b) if there is a  tag where the "name" attribute matches the
> request "Host:" header, then the server will pick that Host to answer this
> request.
>
> 3) Now the server looks at the first line of the request again, to see what
> the browser wants inside that selected Host (here it is thus
> "/something?name1=value1").  In this case, it would be a "web application"
> (or "webapp", or "context"), with the name "/something".
> The webserver now passes the whole browser request (first line, other header
> lines, and maybe also a content), to the application "/something" within
> this Host.
> (and in the case of Tomcat, if there is no such applic

Re: Clarification on --JvmXX windows service installer parameters

[sebb]

On 21 May 2011 01:52, space monkey  wrote:
> Tomcat 7.0.14
> Windows XP+
>
> Hello Tomcat users,
>
> I am trying to understand how the *--JvmMs*, *--JvmMx*, and *JvmSs* windows
> service install paramerters differ from setting the JVM memory values
> explicitly with *--JvmOptions*?
>
> Please see this forum post that described my initial problem:
> http://www.coderanch.com/t/537921/Tomcat/Issues-multiple-Tomcat-services-Windows
> .
>
> Basically, I discovered that I needed to try something like* tomcat7.exe
> //US/t1 --JvmOptions=-Xmx=2048* after finding out that *--JvmMx=2048* did
> not get me the desired results.
>
> How do the --JvmXX flags work exactly and if I am setting memory values with
> JvmOptions, should I still bother setting anything with the --JvmXX?
>
> Thanks!

This looks to be a question on Commons Daemon Procrun, which is documented here:

http://commons.apache.org/daemon/procrun.html

Questions about Commons Daemon ideally belong on the Commons User list.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Feature request: "fullstart" command

[sebb]

On 16 June 2011 11:29, Pid  wrote:
> On 15/06/2011 21:00, Francis GALIEGUE wrote:
>> Tomcat has many abilities to deploy applications at run time (war,
>> tree, context, you name it). However, when used in production, these
>> abilities are used cautiously, if they are used at all.
>>
>> In many scenarios, Tomcat just starts, spends its life, and stops,
>> with a defined set of webapps, and has no automatic deployment
>> capabilities configured in at all. But the builtin startup scripts,
>> and in fact, the Java code itself, lack at least two critical inputs
>> for such scenarios:
>>
>> * Bootstrap will return (and therefore the startup scripts too) before
>> webapps configured at startup time are deployed, and while
>> bootstrapping is fast, deploying applications at startup can be very
>> long;
>> * even with a hackish way (watch the log file to account for complete
>> server startup) in order to wait for webapps to be deployed, there is
>> no status about these deployments at all (has this and that webapp
>> been deployed successfully?).
>
> An application might report that it's started, even it hasn't finished
> initialising.
>
>
>> Proposal: implement a fullstart command to Bootstrap which:
>>
>> * does NOT return until ALL webapps configured at start time are
>> (attempted to be) deployed;
>> * exits with a positive error code representing the number of webapps
>> NOT correctly deployed (or 1 - I don't care as long as it's not 0, but
>> please not -1, think WIFSIGNALED()).
>
> 'fullstart' is an odd name, people might start using it thinking that
> 'start' did not fully start the server.
>
> Returning an exit code which describes the number of apps successfully
> started isn't much use unless you (or the init script) know the number
> of apps configured.
>

And it may cause problems on some OSes which don't use unix-style exit codes.
For example, OpenVMS uses the low order 3 bits of a process exit code
as a severity indicator, and odd is success, even is failure.
[IThe JVM automatically converts exit 0 to exit 1 to compensate, but
cannot deal with all exit codes].

> p
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Feature request: "fullstart" command

[sebb]

On 16 June 2011 12:16, Francis GALIEGUE  wrote:
> On Thu, Jun 16, 2011 at 13:04, sebb  wrote:
> [...]
>>
>> And it may cause problems on some OSes which don't use unix-style exit codes.
>> For example, OpenVMS uses the low order 3 bits of a process exit code
>> as a severity indicator, and odd is success, even is failure.
>> [IThe JVM automatically converts exit 0 to exit 1 to compensate, but
>> cannot deal with all exit codes].
>>
>
> It's up to main() to call System.exit(), so how is that a problem?

If the exit code is not passed to the OS, but is merely a method
return code, then of course it's not a problem.

But I understood the term "exit code" to mean the code returned to the
OS through System.exit().

> --
> Francis Galiegue
> ONE2TEAM
> Ingénieur système
> Mob : +33 (0) 683 877 875
> Tel : +33 (0) 178 945 552
> f...@one2team.com
> 40 avenue Raymond Poincaré
> 75116 Paris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Feature request: "fullstart" command

[sebb]

On 16 June 2011 12:32, Francis GALIEGUE  wrote:
> On Thu, Jun 16, 2011 at 13:30, sebb  wrote:
> [...]
>>>
>>> It's up to main() to call System.exit(), so how is that a problem?
>>
>> If the exit code is not passed to the OS, but is merely a method
>> return code, then of course it's not a problem.
>>
>> But I understood the term "exit code" to mean the code returned to the
>> OS through System.exit().
>>
>
> You lost me. System.exit() acts at the JVM level anyway, therefore the
> process level. Don't we talk about the same thing?

The value passed to System.exit(int) is passed to the OS.

In Unix systems, 0 means success and anything else is generally not success.

OpenVMS behaves differently, as already noted.
If a process returns an error or fatal code to VMS, then by default
the script running it will exit with an error.

So changing the OS exit code can affect existing users.

The point is that exit codes are not portable across OSes; the most
one can hope for is sucess or failure indication.

>
> --
> Francis Galiegue
> ONE2TEAM
> Ingénieur système
> Mob : +33 (0) 683 877 875
> Tel : +33 (0) 178 945 552
> f...@one2team.com
> 40 avenue Raymond Poincaré
> 75116 Paris
>
> -
> 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