date:20120731

With the tomcat locally installed all works fine; the issue occurs from a
linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
machine and a client. Both are in lan without filtering elements.
Since I'm (as now) unable to determine the root cause of the issue (the
worst thing is that the problem is only with some pdf, and it is also
difficult to reproduce), the only solution that worked for me was the
downgrade to the 7.0.26 release.
Regards
Michele MAsè

On Mon, Jul 30, 2012 at 3:46 PM, Jose María Zaragoza
demablo...@gmail.comwrote:

 2012/7/30 Michele Mase' michele.m...@gmail.com:
  IE 6.x on my test pc, but also IE8 with other pcs.
  Acrobat is 9.x, 9.5.1 version, a lot of clients have this version, an
  upgrade is not possible for now.
  I've reviewed the apache access log (when the doc is served by a web
 server
  apache connected with ajp with the tomcat), the only thing I see is an
 http
  206 and a X showing that the client has closed the connection before the
  server %X : X connection aborted before the response completed.
  The security zone is internet.
  To reproduce the issue:
  Utilize the acrobat integrated in the browser
  Install a new tomcat 7.x on a linux machine, not windows with tar zxf
  apache-tomcat-7.x.tar.gz
  Put the pdf in any webapp, the ROOT is enough.
  Obviously use a recent jvm, I use latest version of 1.6 (.33)
  Start the tomcat (sh catalins.sh run or what you prefer)
  Point the browser to the url.
  Every time you want to retry, just empty the browser's cache and kill the
  explorer process.
  Tomcat = 7.0.27 the error occurs
  Tomcat  7.0.27 the error has gone.
  Michele Masè
 


 Sorry, but works fine for me :

 IE 8
 Tomcat 7.0.29 , connecting directly to
 Adobe PDF library 9.90 running into browser
 Same PDF file

 I could only reproduce that error by simulating a network problem (
 changing proxy settings )

 Regards

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

Re: PDF Download problem tomcat = 7.0.27

2012-07-31 Thread Jose María Zaragoza

2012/7/31 Michele Mase' michele.m...@gmail.com:
 With the tomcat locally installed all works fine; the issue occurs from a
 linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
 machine and a client. Both are in lan without filtering elements.
 Since I'm (as now) unable to determine the root cause of the issue (the
 worst thing is that the problem is only with some pdf, and it is also
 difficult to reproduce), the only solution that worked for me was the
 downgrade to the 7.0.26 release.
 Regards
 Michele MAsè


But you said that you've got a Apache web server connected to Tomcat
by AJP,right ?
Which does  it serve PDF file ? If you get PDF file from Tomcat server
directly, does it work fine ?

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

Re: Problems upgrading to Tomcat 7


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alejandro,

On 7/30/12 5:48 PM, Alejandro Mehring wrote:

I'm migrating to Tomcat 7 a web system that used to run on Tomcat
4...


Been there (though I went through 5.5 and 6.0 to get there in a
relatively short amount of time).


So far, I've been able to sort out all of the issues I've faced,
but I'm stuck at one point. When a page loads in Tomcat 4, it goes
and fetches the stylesheet from the server with a link of the form

link type=text/css href=../lightStyle.css rel=stylesheet


Although this should work, I always recommend using context-relative
URLs like this:

link type=text/css href=%=
response.encodeURL(request.getContextPath() + /lightStyle.css) % /

This will ensure that your URLs resolve properly no matter how the
.jsp is being evaluated (for instance, in an include or after a
forward, where the client's URL may not match what your JSP expects).


But on Tomcat 7, the parent directory indirection is removed, and I
can't seem to find the way to prevent this from happening!


That doesn't seem right.


What confuses me more, is that when Tomcat generates the *_jsp.java
files, both 4 and 7 versions generate a line of code like this
one:

out.write(link rel=\stylesheet\ href=\../lightStyle.css\ 
type=\text/css\\r\n\r\n);


So i can't figure out why the rendering process is removing the
'../' bit of the link!


I have a hard time believing that Tomcat is modifying anything: in the
case above, Tomcat does not interpret anything at all. As far as
Tomcat is concerned, the above is just a string of characters like
Hello, World and has no URL context or anything like that.

Are you sure this isn't being included by another JSP or forwarded
from another URL?


Has anyone faced this problem before? I haven't found any parent
directory restriction configuration or something that would point
me in that direction.


What does the output of the JSP look like? That is, what is the actual
content of the page as seen by the client?



+1

And, what does that request for the stylesheet actually look like, when it is sent by the 
client (the browser) to the server ?
You can find that out by using one of the browser plugins like Fiddler2 (for IE), HttpFox 
(for Firefox) or similar.
The point is : this href is interpreted *by the client* and converted to a full HTTP 
request URL (with hostname, path and all), before being sent to the server.

The server always receives an absolute URL, starting at the root.

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

Re: tomcat maven plugin + configuring virtual host for the embedded tomcat ?

2012-07-31 Thread Olivier Lamy

Try last SNAPSHOT (see how here:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html
)

If any issue using this new feature, feel free to reopen:
https://issues.apache.org/jira/browse/MTOMCAT-172

HTH,
--
Olivier

2012/7/31 Albert Kam moonblade.w...@gmail.com:
 Hi,

 I have been developing with tomcat7:run happily for some months now.

 But then i am currently expanding the development where different
 domains would provide different behaviour for the same webapp (imagine
 multitenancy and ACLs based on the domain or the server name)

 To make this work in the development mode,
 i would have to modify the hosts file, mapping several .com domains to
 localhost + add some Alias to the localhost's Host

 Currently i am using the standalone tomcat, doing :
 - go to the parent module, install all modules, which results in the
 newest WAR for the webapp
 - go to the webapp project and tomcat7:deploy to it ..

 Not as fast-development-mode as tomcat7:run (which doesnt include
 installing the modules + WAR building), but this will do :-)

 I may be too hopeful, but is this useful enough to be added as a new
 feature of tomcat maven plugin ?
 I imagine putting these aliases in the plugin's configuration in the pom.xml 
 ..

 Thanks !

 On Tue, Jul 31, 2012 at 12:54 AM, Olivier Lamy ol...@apache.org wrote:
 Hi,
 Not possible currently.
 What is your use case ? those goals are for dev purpose.

 2012/7/27 Albert Kam moonblade.w...@gmail.com:
 I am currently using the snapshot version of tomcat maven plugin.
 And i am using tomcat7:run and tomcat7:run-war-only (for webapps with
 overlay) actively.

 And the time has come for me to try out virtual host .. and as i
 understand it, i have to configure the host, context, etc ..
 But i've been using the embedded tomcat 'supplied' by the tomcat maven
 plugin so far,

 so i wonder if there's a way to configure virtual host on the embedded 
 tomcat ?

 Or should i just forget embedded tomcat and setup an independent
 tomcat i can configure freely ?

 Thank you,
 Albert

 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: tomcat maven plugin + configuring virtual host for the embedded tomcat ?

2012-07-31 Thread Albert Kam

Wow, so fast ! It worked flawlessly :

After adding this in the tomcat maven plugin's configuration ..
aliases
aliasmydomain1.com/alias
aliasmydomain2.com/alias
/aliases

These work with tomcat7:run :
http://localhost:8080
http://mydomain1.com:8080
http://mydomain2.com:8080

Bye2 tomcat:deploy !

Thanks !

On Tue, Jul 31, 2012 at 3:19 PM, Olivier Lamy ol...@apache.org wrote:
 Try last SNAPSHOT (see how here:
 http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html
 )

 If any issue using this new feature, feel free to reopen:
 https://issues.apache.org/jira/browse/MTOMCAT-172

 HTH,
 --
 Olivier

 2012/7/31 Albert Kam moonblade.w...@gmail.com:
 Hi,

 I have been developing with tomcat7:run happily for some months now.

 But then i am currently expanding the development where different
 domains would provide different behaviour for the same webapp (imagine
 multitenancy and ACLs based on the domain or the server name)

 To make this work in the development mode,
 i would have to modify the hosts file, mapping several .com domains to
 localhost + add some Alias to the localhost's Host

 Currently i am using the standalone tomcat, doing :
 - go to the parent module, install all modules, which results in the
 newest WAR for the webapp
 - go to the webapp project and tomcat7:deploy to it ..

 Not as fast-development-mode as tomcat7:run (which doesnt include
 installing the modules + WAR building), but this will do :-)

 I may be too hopeful, but is this useful enough to be added as a new
 feature of tomcat maven plugin ?
 I imagine putting these aliases in the plugin's configuration in the pom.xml 
 ..

 Thanks !

 On Tue, Jul 31, 2012 at 12:54 AM, Olivier Lamy ol...@apache.org wrote:
 Hi,
 Not possible currently.
 What is your use case ? those goals are for dev purpose.

 2012/7/27 Albert Kam moonblade.w...@gmail.com:
 I am currently using the snapshot version of tomcat maven plugin.
 And i am using tomcat7:run and tomcat7:run-war-only (for webapps with
 overlay) actively.

 And the time has come for me to try out virtual host .. and as i
 understand it, i have to configure the host, context, etc ..
 But i've been using the embedded tomcat 'supplied' by the tomcat maven
 plugin so far,

 so i wonder if there's a way to configure virtual host on the embedded 
 tomcat ?

 Or should i just forget embedded tomcat and setup an independent
 tomcat i can configure freely ?

 Thank you,
 Albert

 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




-- 
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)

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

Re: OOME while expanding a war with tomcat 7.0.29 but not with tomcat 7.0.28

2012-07-31 Thread Alberto Aresca

Hi, sorry I was on vacation so I couldn't answer before. The OOME is
heap generated and I can provide you the hapdump since it is generated
automatically when the exception occurs. My JAVA_OPTS are the
following:
JAVA_OPTS=-XX:MaxPermSize=200m -XX:+HeapDumpOnOutOfMemoryError
-Dcom.sun.management.jmxremote -Djava.net.preferIPv4Stack=true
-Djava.awt.headless=true

I'll also give the Bug 53535 workaround a try

Cheers,
Alberto



On Sat, Jul 14, 2012 at 7:13 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Alberto,

 On Jul 14, 2012, at 8:42, Alberto Aresca alberto.are...@gmail.com wrote:

 I've just upgraded my tomcat from version 7.0.28 to the newly released
 7.0.29 but while before my webapp was being expanded without any
 problem, now it is causing an OOME.

 Of course this can be easily fixed by increasing the heap size but
 before going forward in the upgrade i'd like to know if anyone else
 have been experiencing something similar or if something in the
 expansion implementation  changed recently (i couldn't find anything
 in the release note)

 Can you provide any other information? Stack trace or heap dump? Is this 
 regular heap or permgen? What are your heap settings?

 Is there anything else we should know about your web app? Do you have 500 jar 
 files in your lib directory? Do you cache a large dataset on startup?


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




-- 
Alberto Aresca

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

Re: tomcat maven plugin + [default] overlay

2012-07-31 Thread Albert Kam

Hi,

Yes, it is a reactor module, with childwebapp having dependency on the
parentwebapp.
Both webapps are own made (not third parties).

So, i tried these :
- Going to the maven parent module to do the install -- results on
parentwebapp.war and childwebapp.war (overlays with parentwebapp.war)

- On eclipse, on the childwebapp project, i do tomcat7:run ..
  Still the same error of
org.codehaus.plexus.archiver.ArchiverException: The source must not be
a directory

- And then i check the m2e run configuration, and i uncheck 'resolve
workspace artifacts', and rerun it ..
  This time, the error has changed into unfamiliar apache tiles error
that possibly mean the tiles' configuration file is missing or
something

Now this error doesnt appear if i use tomcat7:deploy on the
childwebapp.war, so i assume tomcat7:run has some issues when merging
parentwebapp with childwebapp, resulting in missing files ..

Questions :
- tomcat7:run's tomcat location to help debugging the error :
Is there a temporary directory for the embedded tomcat for the merged
childwebapp, so that i can check what files are probably missing after
tomcat7:run merges parentwebapp and childwebapp ?

- Pure tomcat7:run without building the WAR files ?
Is it possible to have tomcat7:run to merge the dependant webapp
modules without having to build the WAR files ?
For example, tomcat7:run on childwebapp would 'magically' merges
parentwebapp and childwebapp in terms of jars, classes, jsps, and
other static files like xmls, properties, web files, etc (like
overlay, but without making the WAR beforehand) ?

Thank you !

On Tue, Jul 31, 2012 at 12:57 AM, Olivier Lamy ol...@apache.org wrote:
 2012/7/26 Albert Kam moonblade.w...@gmail.com:
 Hello,

 I am having a situation where i couldnt tomcat7:run with overlay in eclipse.
 In the eclipse indigo, i am using the maven plugin, and have imported
 two maven modules,
 the childwebapp which depends on the parentwebapp, which is just like
 a skeleton, with it's own classes, jsps, static resources, but also a
 runnable webapp of itself.
 Doing tomcat7:run on the parentwebapp works well as expected ..

 Here's the dependency in the childwebapp's pom, and i dont have any
 specific overlay configuration :
 dependency
 groupIdgroup.id/groupId
 artifactIdparentwebapp/artifactId
 version${project.version}/version
 typewar/type
 scoperuntime/scope
 /dependency
 This dependency is a reactor modules ? So in this case I presume
 eclipse (m2e) see the build output directory rather than a war file.
 The plugin doesn't have any idea how your war dependency is available
 in an exploded mode (where are the webapp resources and/or classes
 etc..)
 try to install it first.

 When i try running tomcat7:run on the childwebapp, i get this error message,
 as if it tries to find the war of parentwebapp and try to extract it.
 But in my situation, i dont have the war in my development,
 since the eclipse maven plugin already resolves the workspace dependencies.
 I would imagine using the classes from the workspace instead of
 extracting the non-existent war file and load them into the
 childwebapp would solve the issue  ..

 [INFO]
 [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
 @ childwebapp ---
 [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
 resources, i.e. build is platform dependent!
 [INFO] Copying 0 resource
 [INFO]
 [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
 childwebapp ---
 [INFO] Nothing to compile - all classes are up to date
 [INFO]
 [INFO]  tomcat7-maven-plugin:2.0-SNAPSHOT:run (default-cli) @ childwebapp 
 
 [INFO]
 [INFO] --- tomcat7-maven-plugin:2.0-SNAPSHOT:run (default-cli) @ childwebapp 
 ---
 [INFO] Running war on http://localhost:8080/childwebapp
 [INFO] Creating Tomcat server configuration at
 C:\Users\albert\git\Startup\MavenParent\childwebapp\target\tomcat
 [INFO] create webapp with contextPath: /childwebapp
 [ERROR] fail to extract war file
 C:\Users\albert\git\Startup\MavenParent\parentwebapp\target\classes,
 reason:The source must not be a di
 rectory.
 org.codehaus.plexus.archiver.ArchiverException: The source must not be
 a directory.
 at 
 org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
 at 
 org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
 at 
 org.apache.tomcat.maven.common.run.DefaultClassLoaderEntriesCalculator.calculateClassPathEntries(DefaultClassLoaderEntriesCalc
 ulator.java:149)
 at 
 org.apache.tomcat.maven.plugin.tomcat7.run.RunMojo.createWebappLoader(RunMojo.java:254)
 at 
 org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.createContext(AbstractRunMojo.java:563)
 at 
 org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:927)
 at

Re: tomcat maven plugin + configuring virtual host for the embedded tomcat ?

2012-07-31 Thread Albert Kam

Sorry, forgot to mention a suggestion to document this feature in :
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/run-mojo-features.html

Regards,
Albert

On Tue, Jul 31, 2012 at 4:01 PM, Albert Kam moonblade.w...@gmail.com wrote:
 Wow, so fast ! It worked flawlessly :

 After adding this in the tomcat maven plugin's configuration ..
 aliases
 aliasmydomain1.com/alias
 aliasmydomain2.com/alias
 /aliases

 These work with tomcat7:run :
 http://localhost:8080
 http://mydomain1.com:8080
 http://mydomain2.com:8080

 Bye2 tomcat:deploy !

 Thanks !

 On Tue, Jul 31, 2012 at 3:19 PM, Olivier Lamy ol...@apache.org wrote:
 Try last SNAPSHOT (see how here:
 http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html
 )

 If any issue using this new feature, feel free to reopen:
 https://issues.apache.org/jira/browse/MTOMCAT-172

 HTH,
 --
 Olivier

 2012/7/31 Albert Kam moonblade.w...@gmail.com:
 Hi,

 I have been developing with tomcat7:run happily for some months now.

 But then i am currently expanding the development where different
 domains would provide different behaviour for the same webapp (imagine
 multitenancy and ACLs based on the domain or the server name)

 To make this work in the development mode,
 i would have to modify the hosts file, mapping several .com domains to
 localhost + add some Alias to the localhost's Host

 Currently i am using the standalone tomcat, doing :
 - go to the parent module, install all modules, which results in the
 newest WAR for the webapp
 - go to the webapp project and tomcat7:deploy to it ..

 Not as fast-development-mode as tomcat7:run (which doesnt include
 installing the modules + WAR building), but this will do :-)

 I may be too hopeful, but is this useful enough to be added as a new
 feature of tomcat maven plugin ?
 I imagine putting these aliases in the plugin's configuration in the 
 pom.xml ..

 Thanks !

 On Tue, Jul 31, 2012 at 12:54 AM, Olivier Lamy ol...@apache.org wrote:
 Hi,
 Not possible currently.
 What is your use case ? those goals are for dev purpose.

 2012/7/27 Albert Kam moonblade.w...@gmail.com:
 I am currently using the snapshot version of tomcat maven plugin.
 And i am using tomcat7:run and tomcat7:run-war-only (for webapps with
 overlay) actively.

 And the time has come for me to try out virtual host .. and as i
 understand it, i have to configure the host, context, etc ..
 But i've been using the embedded tomcat 'supplied' by the tomcat maven
 plugin so far,

 so i wonder if there's a way to configure virtual host on the embedded 
 tomcat ?

 Or should i just forget embedded tomcat and setup an independent
 tomcat i can configure freely ?

 Thank you,
 Albert

 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




 --
 Do not pursue the past. Do not lose yourself in the future.
 The past no longer is. The future has not yet come.
 Looking deeply at life as it is in the very here and now,
 the practitioner dwells in stability and freedom.
 (Thich Nhat Hanh)



-- 
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)

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

Re: PDF Download problem tomcat = 7.0.27

Unluckly the problem is difficult to reproduce (almost 1/10 times appears);
a small script that empty the IE's cache and kill explorer.exe helped me.
I used mod_proxy_ajp because the apache's logs were better for debugging
purposes.
The matter appears even using the http bio connector.
Michele MAsè

On Tue, Jul 31, 2012 at 9:52 AM, Jose María Zaragoza
demablo...@gmail.comwrote:

 2012/7/31 Michele Mase' michele.m...@gmail.com:
  With the tomcat locally installed all works fine; the issue occurs from a
  linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
  machine and a client. Both are in lan without filtering elements.
  Since I'm (as now) unable to determine the root cause of the issue (the
  worst thing is that the problem is only with some pdf, and it is also
  difficult to reproduce), the only solution that worked for me was the
  downgrade to the 7.0.26 release.
  Regards
  Michele MAsè
 

 But you said that you've got a Apache web server connected to Tomcat
 by AJP,right ?
 Which does  it serve PDF file ? If you get PDF file from Tomcat server
 directly, does it work fine ?

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

Re: PDF Download problem tomcat = 7.0.27


Michele Mase' wrote:

Unluckly the problem is difficult to reproduce (almost 1/10 times appears);
a small script that empty the IE's cache and kill explorer.exe helped me.
I used mod_proxy_ajp because the apache's logs were better for debugging
purposes.
The matter appears even using the http bio connector.
Michele MAsè


If it happens 1 time out of 10, then it is not hard to reproduce.
Again :
- install one of the plugins earlier mentioned
- activate it
- load your PDF once
- press the page refresh, with the shift button pressed (forces reload, even when 
already in cache)

- do this as long as you do not have the problem
- when you have the problem, look at the display of the plugin. Highlight the request that 
did not come back with an OK response (OK=200), and display the request and response 
headers of that request. Copy them to the clipboard, and paste them in you next message to 
the list.


Without solid information of that kind, it is difficult to help you further.

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

Re: Best practice for redeployments

2012-07-31 Thread David kerber


On 7/30/2012 8:32 PM, Hassan Schroeder wrote:

On Mon, Jul 30, 2012 at 2:57 PM,llow...@oreillyauto.com  wrote:


Currently, each night we wipe out the wars and then redeploy them with
fresh copies ...


?!


What's the general consensus for the best practice for this?


Uh, don't ?


+1





Are nightly  tomcat restarts even needed  ...


I have legacy apps that run for months, and then only get restarted
when Tomcat itself is upgraded.


Yup.  Or when OS updates are applied and require a reboot.





Any recommendations or thoughts or suggestions would be greatly
appreciated. I'm sure there is some room for improvement in how we do
things, but I was wondering what was considered a standard practice in
this area.


Also, I only mount the spare tire on my car when one of the other four
is flat. Irresponsible slacker, I know, but ...

FWIW, YMMV, etc.



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

Re: Best practice for redeployments

2012-07-31 Thread Pid

On 30/07/2012 22:57, llow...@oreillyauto.com wrote:
 All,
 
 I have  70-80 apps that are spread out across 3 different clusters (based
 on usage, availability needs etc)
 
 Currently, each night we wipe out the wars and then redeploy them with
 fresh copies from the end points of our promotion paths (one for test and
 one for prod).
 
 What's the general consensus for the best practice for this?
 
 Do people generally only redeploy whatever has changed?
 
 Are nightly  tomcat restarts even needed (or recommended), or should we
 just hot-deploy things at fixed times (based on traffic patterns) but only
 if something is needing to be updated?
 
 Any recommendations or thoughts or suggestions would be greatly
 appreciated. I'm sure there is some room for improvement in how we do
 things, but I was wondering what was considered a standard practice in
 this area.
 
 Lee Lowder

In future please start a completely new email, rather than replying to
an existing email* just editing the subject/body (which is call thread
hijacking).


p


* Re: Best practice for redeployments

-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: Problems upgrading to Tomcat 7

First of all, thank you very much for your quick response! I'm too having a
hard time believing that tomcat would do something like that... I even
tried on a new web project and it didn't remove the parent directory
reference! I'm very confused right now...

The base url of the application is of the form

http://host/app/servlets/FrontController

So when in Tomcat 4 the page fetches the stylesheet (using the
href=../lightStyle.css form), it resolves to
http://host/app/lightStyle.css, whereas in Tomcat 7 it goes to
http://host/app/servlets/lightStyle.css.

Here's the output of the JSP (the header part) for both 4 and 7 version.

TOMCAT 4


html
style type=text/css
@import URL(../lightStyle.css)
/style
head
!--meta http-equiv=Content-Type content=text/html;
charset=windows-1252--
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
meta http-equiv=Expires content=0
meta http-equiv=Pragma content=no-cache
meta http-equiv=cache-control content=no-cache
titleConsulta de usuarios/title
link rel=stylesheet href=../lightStyle.css type=text/css
...
/head
...



TOMCAT 7

HTML
style type=text/css
@import URL(lightStyle.css)
/style
head
titleError/title
link rel=stylesheet href=lightStyle.css type=text/css
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
meta http-equiv=Expires content=0
meta http-equiv=Pragma content=no-cache
meta http-equiv=cache-control content=no-cache
...
/head
...


Thanks again for anything you can think of!
Cheers!
Ale


On Tue, Jul 31, 2012 at 5:10 AM, André Warnier a...@ice-sa.com wrote:

 Christopher Schultz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Alejandro,

 On 7/30/12 5:48 PM, Alejandro Mehring wrote:

 I'm migrating to Tomcat 7 a web system that used to run on Tomcat
 4...


 Been there (though I went through 5.5 and 6.0 to get there in a
 relatively short amount of time).

  So far, I've been able to sort out all of the issues I've faced,
 but I'm stuck at one point. When a page loads in Tomcat 4, it goes
 and fetches the stylesheet from the server with a link of the form

 link type=text/css href=../lightStyle.css rel=stylesheet


 Although this should work, I always recommend using context-relative
 URLs like this:

 link type=text/css href=%=
 response.encodeURL(request.**getContextPath() + /lightStyle.css) % /

 This will ensure that your URLs resolve properly no matter how the
 .jsp is being evaluated (for instance, in an include or after a
 forward, where the client's URL may not match what your JSP expects).

  But on Tomcat 7, the parent directory indirection is removed, and I
 can't seem to find the way to prevent this from happening!


 That doesn't seem right.

  What confuses me more, is that when Tomcat generates the *_jsp.java
 files, both 4 and 7 versions generate a line of code like this
 one:

 out.write(link rel=\stylesheet\ href=\../lightStyle.css\
 type=\text/css\\r\n\r\n);

 So i can't figure out why the rendering process is removing the
 '../' bit of the link!


 I have a hard time believing that Tomcat is modifying anything: in the
 case above, Tomcat does not interpret anything at all. As far as
 Tomcat is concerned, the above is just a string of characters like
 Hello, World and has no URL context or anything like that.

 Are you sure this isn't being included by another JSP or forwarded
 from another URL?

  Has anyone faced this problem before? I haven't found any parent
 directory restriction configuration or something that would point
 me in that direction.


 What does the output of the JSP look like? That is, what is the actual
 content of the page as seen by the client?


 +1

 And, what does that request for the stylesheet actually look like, when it
 is sent by the client (the browser) to the server ?
 You can find that out by using one of the browser plugins like Fiddler2
 (for IE), HttpFox (for Firefox) or similar.
 The point is : this href is interpreted *by the client* and converted to
 a full HTTP request URL (with hostname, path and all), before being sent to
 the server.
 The server always receives an absolute URL, starting at the root.


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

Re: Best practice for redeployments

2012-07-31 Thread llowder

Pid,

My apologies, I did not realize that I was hijacking.
With how my mail client works I had thought I was starting a new thread.

Lee Lowder




From:   Pid p...@pidster.com
To: Tomcat Users List users@tomcat.apache.org
Date:   07/31/2012 07:20 AM
Subject:Re: Best practice for redeployments



On 30/07/2012 22:57, llow...@oreillyauto.com wrote:
 All,

 I have  70-80 apps that are spread out across 3 different clusters (based
 on usage, availability needs etc)

 Currently, each night we wipe out the wars and then redeploy them with
 fresh copies from the end points of our promotion paths (one for test and
 one for prod).

 What's the general consensus for the best practice for this?

 Do people generally only redeploy whatever has changed?

 Are nightly  tomcat restarts even needed (or recommended), or should we
 just hot-deploy things at fixed times (based on traffic patterns) but
only
 if something is needing to be updated?

 Any recommendations or thoughts or suggestions would be greatly
 appreciated. I'm sure there is some room for improvement in how we do
 things, but I was wondering what was considered a standard practice in
 this area.

 Lee Lowder

In future please start a completely new email, rather than replying to
an existing email* just editing the subject/body (which is call thread
hijacking).


p


* Re: Best practice for redeployments

--

[key:62590808]

[attachment signature.asc deleted by Lee Lowder/OReilly]

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.

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

Re: Problems upgrading to Tomcat 7

2012-07-31 Thread Tim Watts

On Tue, 2012-07-31 at 09:20 -0300, Alejandro Mehring wrote:
 First of all, thank you very much for your quick response! I'm too having a
 hard time believing that tomcat would do something like that... I even
 tried on a new web project and it didn't remove the parent directory
 reference! I'm very confused right now...
 
 The base url of the application is of the form
 
 http://host/app/servlets/FrontController
 
 So when in Tomcat 4 the page fetches the stylesheet (using the
 href=../lightStyle.css form), it resolves to
 http://host/app/lightStyle.css, whereas in Tomcat 7 it goes to
 http://host/app/servlets/lightStyle.css.
 

In your 4-7 migration process have you made any source code changes
(e.g. using base tags)?


 Here's the output of the JSP (the header part) for both 4 and 7 version.
 
 TOMCAT 4
 
 
 html
 style type=text/css
 @import URL(../lightStyle.css)
 /style
 head
 !--meta http-equiv=Content-Type content=text/html;
 charset=windows-1252--
 meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
 meta http-equiv=Expires content=0
 meta http-equiv=Pragma content=no-cache
 meta http-equiv=cache-control content=no-cache
 titleConsulta de usuarios/title
 link rel=stylesheet href=../lightStyle.css type=text/css
 ...
 /head
 ...
 
 
 
 TOMCAT 7
 
 HTML
 style type=text/css
 @import URL(lightStyle.css)
 /style
 head
 titleError/title
 link rel=stylesheet href=lightStyle.css type=text/css
 meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
 meta http-equiv=Expires content=0
 meta http-equiv=Pragma content=no-cache
 meta http-equiv=cache-control content=no-cache
 ...
 /head
 ...
 
 
 Thanks again for anything you can think of!
 Cheers!
 Ale
 
 
 On Tue, Jul 31, 2012 at 5:10 AM, André Warnier a...@ice-sa.com wrote:
 
  Christopher Schultz wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Alejandro,
 
  On 7/30/12 5:48 PM, Alejandro Mehring wrote:
 
  I'm migrating to Tomcat 7 a web system that used to run on Tomcat
  4...
 
 
  Been there (though I went through 5.5 and 6.0 to get there in a
  relatively short amount of time).
 
   So far, I've been able to sort out all of the issues I've faced,
  but I'm stuck at one point. When a page loads in Tomcat 4, it goes
  and fetches the stylesheet from the server with a link of the form
 
  link type=text/css href=../lightStyle.css rel=stylesheet
 
 
  Although this should work, I always recommend using context-relative
  URLs like this:
 
  link type=text/css href=%=
  response.encodeURL(request.**getContextPath() + /lightStyle.css) % /
 
  This will ensure that your URLs resolve properly no matter how the
  .jsp is being evaluated (for instance, in an include or after a
  forward, where the client's URL may not match what your JSP expects).
 
   But on Tomcat 7, the parent directory indirection is removed, and I
  can't seem to find the way to prevent this from happening!
 
 
  That doesn't seem right.
 
   What confuses me more, is that when Tomcat generates the *_jsp.java
  files, both 4 and 7 versions generate a line of code like this
  one:
 
  out.write(link rel=\stylesheet\ href=\../lightStyle.css\
  type=\text/css\\r\n\r\n);
 
  So i can't figure out why the rendering process is removing the
  '../' bit of the link!
 
 
  I have a hard time believing that Tomcat is modifying anything: in the
  case above, Tomcat does not interpret anything at all. As far as
  Tomcat is concerned, the above is just a string of characters like
  Hello, World and has no URL context or anything like that.
 
  Are you sure this isn't being included by another JSP or forwarded
  from another URL?
 
   Has anyone faced this problem before? I haven't found any parent
  directory restriction configuration or something that would point
  me in that direction.
 
 
  What does the output of the JSP look like? That is, what is the actual
  content of the page as seen by the client?
 
 
  +1
 
  And, what does that request for the stylesheet actually look like, when it
  is sent by the client (the browser) to the server ?
  You can find that out by using one of the browser plugins like Fiddler2
  (for IE), HttpFox (for Firefox) or similar.
  The point is : this href is interpreted *by the client* and converted to
  a full HTTP request URL (with hostname, path and all), before being sent to
  the server.
  The server always receives an absolute URL, starting at the root.
 
 
  --**--**-
  To unsubscribe, e-mail: 
  users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 



signature.asc
Description: This is a digitally signed message part

Re: Problems upgrading to Tomcat 7


Alejandro Mehring wrote:
...



The base url of the application is of the form

http://host/app/servlets/FrontController

So when in Tomcat 4 the page fetches the stylesheet (using the
href=../lightStyle.css form), it resolves to
http://host/app/lightStyle.css, whereas in Tomcat 7 it goes to
http://host/app/servlets/lightStyle.css.


How do you *know* this ?
Are you watching what the browser really sends as a HTTP request URL, and if 
yes how ?



Here's the output of the JSP (the header part) for both 4 and 7 version.



Can you also paste the content of the real JSP page which generates the output you showed 
below ? Is that JSP page *exactly* the same for the Tomcats 4 and 7 servers ?



TOMCAT 4


html
style type=text/css
@import URL(../lightStyle.css)
/style
head
!--meta http-equiv=Content-Type content=text/html;
charset=windows-1252--
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
meta http-equiv=Expires content=0
meta http-equiv=Pragma content=no-cache
meta http-equiv=cache-control content=no-cache
titleConsulta de usuarios/title
link rel=stylesheet href=../lightStyle.css type=text/css
...
/head
...



TOMCAT 7

HTML
style type=text/css
@import URL(lightStyle.css)
/style
head
titleError/title
link rel=stylesheet href=lightStyle.css type=text/css
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
meta http-equiv=Expires content=0
meta http-equiv=Pragma content=no-cache
meta http-equiv=cache-control content=no-cache
...
/head
...


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

Re: Problems upgrading to Tomcat 7

Thank you very much for your help!

Digging a bit more into the system, I came to a part where it's building
the link based on the original servlet request.

If I have this URL:
http://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something

Java 1.4's getRequestURL() returns 'http://host/app/servlet/FrontController'
whereas
Java 1.6's getRequestURL() returns 'http://host/app/target.jsp'

I found someone reporting this same issue on JBoss community page, but got
no answer. I'll try to find another way to get the same behaviour in Java
1.6 as of getRequestURL in 1.4.


Thank you very much for your kind help.
Ale

On Tue, Jul 31, 2012 at 10:55 AM, André Warnier a...@ice-sa.com wrote:

 Alejandro Mehring wrote:
 ...


 The base url of the application is of the form

 http://host/app/servlets/**FrontControllerhttp://host/app/servlets/FrontController

 So when in Tomcat 4 the page fetches the stylesheet (using the
 href=../lightStyle.css form), it resolves to
 http://host/app/lightStyle.css**, whereas in Tomcat 7 it goes to
 http://host/app/servlets/**lightStyle.csshttp://host/app/servlets/lightStyle.css
 .


 How do you *know* this ?
 Are you watching what the browser really sends as a HTTP request URL, and
 if yes how ?



 Here's the output of the JSP (the header part) for both 4 and 7 version.


 Can you also paste the content of the real JSP page which generates the
 output you showed below ? Is that JSP page *exactly* the same for the
 Tomcats 4 and 7 servers ?


  TOMCAT 4
 

 html
 style type=text/css
 @import URL(../lightStyle.css)
 /style
 head
 !--meta http-equiv=Content-Type content=text/html;
 charset=windows-1252--
 meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
 meta http-equiv=Expires content=0
 meta http-equiv=Pragma content=no-cache
 meta http-equiv=cache-control content=no-cache
 titleConsulta de usuarios/title
 link rel=stylesheet href=../lightStyle.css type=text/css
 ...
 /head
 ...



 TOMCAT 7
 
 HTML
 style type=text/css
 @import URL(lightStyle.css)
 /style
 head
 titleError/title
 link rel=stylesheet href=lightStyle.css type=text/css
 meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
 meta http-equiv=Expires content=0
 meta http-equiv=Pragma content=no-cache
 meta http-equiv=cache-control content=no-cache
 ...
 /head
 ...


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

Re: Problems upgrading to Tomcat 7


Alejandro Mehring wrote:

Thank you very much for your help!

Digging a bit more into the system, I came to a part where it's building
the link based on the original servlet request.

If I have this URL:
http://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something

Java 1.4's getRequestURL() returns 'http://host/app/servlet/FrontController'
whereas
Java 1.6's getRequestURL() returns 'http://host/app/target.jsp'

I found someone reporting this same issue on JBoss community page, but got
no answer. I'll try to find another way to get the same behaviour in Java
1.6 as of getRequestURL in 1.4.



Now you seem to be on the right path.
On the other hand, you seem to be strangely ignoring every bit of advice that people are 
trying to give you, for example what Christopher suggested in his earlier message, and 
which i will repeat here :


quote

Although this should work, I always recommend using context-relative
URLs like this:

link type=text/css href=%=
response.encodeURL(request.getContextPath() + /lightStyle.css) % /

This will ensure that your URLs resolve properly no matter how the
.jsp is being evaluated (for instance, in an include or after a
forward, where the client's URL may not match what your JSP expects).

unquote


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

Re: PDF Download problem tomcat = 7.0.27

The only way to reproduce it is (for me) without the plugin; i'm sorry ...
I haven't seen what happens using a sniffer, but the X in the apache's log
file tells me that the client is aborting the session, I suspect a session
reset could happen.
And finally, following your suggestion, a F5 helped me:

200Ok session:
GET /test.pdf HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: application/pdf
Content-Length: 3447866
Date: Tue, 31 Jul 2012 12:32:05 GMT

206KO:
GET /test.pdf HTTP/1.1
Accept: */*
Range: bytes=3446021-3447865, 475136-1792507
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
Date: Tue, 31 Jul 2012 12:32:20 GMT
Content-Length: 1319458

Michele Masè

On Tue, Jul 31, 2012 at 1:30 PM, André Warnier a...@ice-sa.com wrote:

 Michele Mase' wrote:

 Unluckly the problem is difficult to reproduce (almost 1/10 times
 appears);
 a small script that empty the IE's cache and kill explorer.exe helped me.
 I used mod_proxy_ajp because the apache's logs were better for debugging
 purposes.
 The matter appears even using the http bio connector.
 Michele MAsè

  If it happens 1 time out of 10, then it is not hard to reproduce.
 Again :
 - install one of the plugins earlier mentioned
 - activate it
 - load your PDF once
 - press the page refresh, with the shift button pressed (forces reload,
 even when already in cache)
 - do this as long as you do not have the problem
 - when you have the problem, look at the display of the plugin. Highlight
 the request that did not come back with an OK response (OK=200), and
 display the request and response headers of that request. Copy them to the
 clipboard, and paste them in you next message to the list.

 Without solid information of that kind, it is difficult to help you
 further.


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

Re: Problems upgrading to Tomcat 7

I'm very sorry! I forgot to mention that i tried what he suggested, but got
the same result. That's why I started digging more into it and got to that
point and what helped me find this other issue.

Thanks again!
Ale

On Tue, Jul 31, 2012 at 11:31 AM, André Warnier a...@ice-sa.com wrote:

 Alejandro Mehring wrote:

 Thank you very much for your help!

 Digging a bit more into the system, I came to a part where it's building
 the link based on the original servlet request.

 If I have this URL:
 http://host/app/servlet/**FrontController?arg1=yesarg2=**
 target.jsparg3=somethinghttp://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something

 Java 1.4's getRequestURL() returns 'http://host/app/servlet/**
 FrontController http://host/app/servlet/FrontController'
 whereas
 Java 1.6's getRequestURL() returns 'http://host/app/target.jsp'

 I found someone reporting this same issue on JBoss community page, but got
 no answer. I'll try to find another way to get the same behaviour in Java
 1.6 as of getRequestURL in 1.4.


 Now you seem to be on the right path.
 On the other hand, you seem to be strangely ignoring every bit of advice
 that people are trying to give you, for example what Christopher suggested
 in his earlier message, and which i will repeat here :

 quote


 Although this should work, I always recommend using context-relative
 URLs like this:

 link type=text/css href=%=
 response.encodeURL(request.**getContextPath() + /lightStyle.css) % /

 This will ensure that your URLs resolve properly no matter how the
 .jsp is being evaluated (for instance, in an include or after a
 forward, where the client's URL may not match what your JSP expects).

 unquote



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

Re: Problems upgrading to Tomcat 7

2012-07-31 Thread Mark Thomas

On 31/07/2012 15:07, Alejandro Mehring wrote:
 Thank you very much for your help!
 
 Digging a bit more into the system, I came to a part where it's building
 the link based on the original servlet request.
 
 If I have this URL:
 http://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something
 
 Java 1.4's getRequestURL() returns 'http://host/app/servlet/FrontController'
 whereas
 Java 1.6's getRequestURL() returns 'http://host/app/target.jsp'
 
 I found someone reporting this same issue on JBoss community page, but got
 no answer. I'll try to find another way to get the same behaviour in Java
 1.6 as of getRequestURL in 1.4.

That is not a Java 1.4 vs Java 6 issue. That is a container
implementation issue since getRequestURL() is provided by the container.

You'll need to dig a little more into exactly what is going on in the
app. I don't recall any spec changes in this area.

Mark


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

Re: Problems upgrading to Tomcat 7

Thank you, Mark!

I'll look into the container and let you know when i find the solution.

Cheers,
Ale

On Tue, Jul 31, 2012 at 11:57 AM, Mark Thomas ma...@apache.org wrote:

 On 31/07/2012 15:07, Alejandro Mehring wrote:
  Thank you very much for your help!
 
  Digging a bit more into the system, I came to a part where it's building
  the link based on the original servlet request.
 
  If I have this URL:
 
 http://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something
 
  Java 1.4's getRequestURL() returns '
 http://host/app/servlet/FrontController'
  whereas
  Java 1.6's getRequestURL() returns 'http://host/app/target.jsp'
 
  I found someone reporting this same issue on JBoss community page, but
 got
  no answer. I'll try to find another way to get the same behaviour in Java
  1.6 as of getRequestURL in 1.4.

 That is not a Java 1.4 vs Java 6 issue. That is a container
 implementation issue since getRequestURL() is provided by the container.

 You'll need to dig a little more into exactly what is going on in the
 app. I don't recall any spec changes in this area.

 Mark


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

Re: Problems upgrading to Tomcat 7


Alejandro Mehring wrote:

I'm very sorry! I forgot to mention that i tried what he suggested, but got
the same result. That's why I started digging more into it and got to that
point and what helped me find this other issue.

Allright, but next time try to provide some feedback.  People on the list are people, and 
they may tend to get discouraged from helping you, if you /appear/ to ignore what they are 
saying and continue on your own track no matter what.



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

Re: PDF Download problem tomcat = 7.0.27


Michele Mase' wrote:

The only way to reproduce it is (for me) without the plugin; i'm sorry ...
I haven't seen what happens using a sniffer, but the X in the apache's log
file tells me that the client is aborting the session, I suspect a session
reset could happen.
And finally, following your suggestion, a F5 helped me:

200Ok session:
GET /test.pdf HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: application/pdf
Content-Length: 3447866
Date: Tue, 31 Jul 2012 12:32:05 GMT

206KO:
GET /test.pdf HTTP/1.1
Accept: */*
Range: bytes=3446021-3447865, 475136-1792507
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
Date: Tue, 31 Jul 2012 12:32:20 GMT
Content-Length: 1319458



The above appears (to me) to be two correct request/response pairs.
Even the 206, which is a normal response to the Range request as per here : 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


We still don't know if/why the browser/client resets the connection, but it is not visible 
in the above exchange.

Maybe inspecting the response body to the second request would provide a clue.

It is also a bit of a mystery to me why the same browser would sometimes request the same 
resource in one go, and sometimes as byteranges.  But I don't know exactly how this part 
is supposed to work.

Maybe it depends on which part of the PDF the user decides to display ?

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

Re: Problems upgrading to Tomcat 7

2012-07-31 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alejandro,

On 7/31/12 10:07 AM, Alejandro Mehring wrote:
 Digging a bit more into the system, I came to a part where it's
 building the link based on the original servlet request.
 
 If I have this URL: 
 http://host/app/servlet/FrontController?arg1=yesarg2=target.jsparg3=something

  Java 1.4's getRequestURL() returns
 'http://host/app/servlet/FrontController' whereas Java 1.6's
 getRequestURL() returns 'http://host/app/target.jsp'
 
 I found someone reporting this same issue on JBoss community page,
 but got no answer. I'll try to find another way to get the same
 behaviour in Java 1.6 as of getRequestURL in 1.4.

If getRequestURL (from the servlet API, not from the Java API) returns
something different, then something must have changed in your webapp.
The original request (what the client sent) looks like what? Are there
any forwards involved? It looks like you are forwarding from
/servlet/FrontController to /target.jsp. When you do that, the request
URI changes. If you want the original request URI, then you have to
look in the request attributes. I'll point you to the servlet spec to
find out the name(s) of the attribute(s) to fetch if that's what you want.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAX+jQACgkQ9CaO5/Lv0PDWvgCfZ9zqYwtST79UxQ8sO6sYY4Nb
mB4An37ynSb3YxEaKrTBukFXeVf6ylg1
=32Zy
-END PGP SIGNATURE-

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

Re: Problems upgrading to Tomcat 7

2012-07-31 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alejandro,

On 7/31/12 8:20 AM, Alejandro Mehring wrote:
 The base url of the application is of the form
 
 http://host/app/servlets/FrontController

Is that an HTTP base tag, or just the base of the webapp that you
use as a mental model?

 So when in Tomcat 4 the page fetches the stylesheet (using the 
 href=../lightStyle.css form), it resolves to 
 http://host/app/lightStyle.css, whereas in Tomcat 7 it goes to 
 http://host/app/servlets/lightStyle.css.
 
 Here's the output of the JSP (the header part) for both 4 and 7
 version.
 
 TOMCAT 4 
 
 html style type=text/css @import URL(../lightStyle.css) 
 /style head !--meta http-equiv=Content-Type
 content=text/html; charset=windows-1252-- meta
 http-equiv=Content-Type content=text/html; charset=ISO-8859-1 
 meta http-equiv=Expires content=0 meta http-equiv=Pragma
 content=no-cache meta http-equiv=cache-control
 content=no-cache titleConsulta de usuarios/title link
 rel=stylesheet href=../lightStyle.css type=text/css ... 
 /head ...
 
 
 
 TOMCAT 7  HTML style type=text/css @import
 URL(lightStyle.css) /style head titleError/title link
 rel=stylesheet href=lightStyle.css type=text/css meta
 http-equiv=Content-Type content=text/html; charset=ISO-8859-1 
 meta http-equiv=Expires content=0 meta http-equiv=Pragma
 content=no-cache meta http-equiv=cache-control
 content=no-cache ... /head ...

Something doesn't look right here. There are lots of differences
between these two outputs:

1. html versus HTML
2. Missing !-- comment -- in TC7 version
3. Re-arranged HTML tags (title/link versus meta)
4. Different language and/or meaning for title (Error versus
   Consulta de usuarios)

Are you sure you aren't just seeing the error page in TC7 because
something is broken and you think that the Consulta de usuarios page
should be showing instead?

It sounds like a case of mistaken identity. You are probably editing
the wrong page and trying to solve the wrong problem.

Read your log files to see what is really going wrong.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAX+ygACgkQ9CaO5/Lv0PCkSwCfVZmgQ9mwVPf5BP+GVJpvHpJn
AY0AniG6vXFAHGOYrmZDbtXBsHz0r0Xq
=TVES
-END PGP SIGNATURE-

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

RE: Permanent servlet in TC7

2012-07-31 Thread Chip McVey

Thanks to all for the input - I am ending up doing some refactoring to follow 
Ben's advice wrt a POJO that does the heavy lifting stored in context, making 
the destroy() essentially a no-op rather than doing full shutdown, and using 
the ContextListener to really do final shutdown using the POJO when the context 
itself is destroyed.

-Original Message-
From: Ben Souther [mailto:b...@souther.us] 
Sent: Friday, July 27, 2012 1:56 PM
To: users@tomcat.apache.org
Subject: RE: Permanent servlet in TC7

On Thu, 2012-07-26 at 19:54 +, Chip McVey wrote:
 So I'm looking for a guarantee that no automatic destroys will happen 
 going forward just because Tomcat decides to do it on its own.  If it 
 is instructed to shutdown/undeploy/unload by some outside system or by 
 a human user, that's fine, I'm not worried about that.  But I don't 
 want these servlets to be destroyed just because Tomcat decides to do 
 so for whatever reason.

If I were looking for permanence, I would create POJO, bind it to context 
scope, and then call it from my servlets, passing it whatever it needs to 
function.

Re: Problem with tomcat and jk module

2012-07-31 Thread Piotr Wąchała


Hi,
sorry i dident wrote before but we fight with the problem.
My coleege from work, restart few switches and we think this was the 
problem.
No we observe in logs only [info] without errors or whitout disconecting 
clients from our network


Piotr


W dniu 2012-07-24 18:30, Piotr Wąchała pisze:

ok, thanks for advice, but I checked my front end enviroment.
Before connection goes to front end apache, must go to firewall and 
next to load balancer.

I remove from this chain load balancer, and it was still the same.
In firewall I dont observe teardown connecion or sth. like that. (I 
can`t quit the firewall from this chain)
I try to attach pid and tid form tomcat to apache(adding %P %{tid}P %D 
to apache LogFormat) and search the problem, but I think it isent good 
clue. I cant exactly correkate problem in jklogfile and apache access.log
The funny thing is the whole system works ok. for over 2y and in last 
week just from day to another day it starts to work terrible.

I even change my isp, still no progress.

Q: What is causing that connection to close, before the response can 
be sent ?

A: I will try to answer to this after 9pm.

Piotr

W dniu 2012-07-24 15:12, André Warnier pisze:

Hi.

Thanks for the very complete information about your environment.

Piotr Wąchała wrote:

Hi,
Maybe someone can help me with my tomcat problem.
Hope that wont be a big problem for you.

Im observing that our client are disconnected from server, that is 
very bad situation.



In my experience, this kind of message :


In jklogfile.log
[Tue Jul 24 08:43:22 2012] [17466:47245693265248] [info] 
jk_handler::mod_jk.c (2620): Aborting connection for 
worker=loadbalancer
[Tue Jul 24 08:43:22 2012] [17023:47245693265248] [info] 
ajp_process_callback::jk_ajp_common.c (1885): Writing to client 
aborted or client network problems
[Tue Jul 24 08:43:22 2012] [17023:47245693265248] [info] 
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to 
tomcat failed (unrecoverable), because of client write error 
(attempt=1)


in 99% of the cases, indicates a problem that is NOT with Apache 
httpd or mod_jk or Tomcat.
It is that by the time (tomcat+mod_jk+apache) want to send a response 
back to the client (the user's browser), the eonnection to that 
user's browser does not exist anymore, so they cannot send it. (And 
all the other messages after that, are because after this error, 
things kind of get out of sync.)


This can happen
- either because the user in front of that browser decides that he 
has waited long enough, and clicks on another link (or closes the 
browser)
- or because some piece of equipment or software closes that 
connection before (tomcat+mod_jk+apache) had a chance to send back 
the response


(It happens that in-between routers/firewalls/gatewaysw/proxies, if 
they do not see anything happen on a client connection for a while, 
will close that connection - to gain on the number of connections 
that they must manage).


(Both either/or causes above are also more likely if your Tomcat 
requests are so that they take a long time to be processed and 
generate a response)


So the first place to look, is the link between your client 
(presumably a user browser) and the front-end Apache.  What is 
causing that connection to close, before the response can be sent ?




-
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






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

Re: tomcat maven plugin + configuring virtual host for the embedded tomcat ?

2012-07-31 Thread Olivier Lamy

documentation added here:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html#aliases

2012/7/31 Albert Kam moonblade.w...@gmail.com:
Sorry, forgot to mention a suggestion to document this feature in :
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/run-mojo-features.html

Regards,
Albert

On Tue, Jul 31, 2012 at 4:01 PM, Albert Kam moonblade.w...@gmail.com wrote:
Wow, so fast ! It worked flawlessly :

After adding this in the tomcat maven plugin's configuration ..
aliases
aliasmydomain1.com/alias
aliasmydomain2.com/alias
/aliases

These work with tomcat7:run :
http://localhost:8080
http://mydomain1.com:8080
http://mydomain2.com:8080

Bye2 tomcat:deploy !

Thanks !

On Tue, Jul 31, 2012 at 3:19 PM, Olivier Lamy ol...@apache.org wrote:
Try last SNAPSHOT (see how here:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html
)

If any issue using this new feature, feel free to reopen:
https://issues.apache.org/jira/browse/MTOMCAT-172

HTH,
--
Olivier

2012/7/31 Albert Kam moonblade.w...@gmail.com:
Hi,

I have been developing with tomcat7:run happily for some months now.

But then i am currently expanding the development where different
domains would provide different behaviour for the same webapp (imagine
multitenancy and ACLs based on the domain or the server name)

To make this work in the development mode,
i would have to modify the hosts file, mapping several .com domains to
localhost + add some Alias to the localhost's Host

Currently i am using the standalone tomcat, doing :
- go to the parent module, install all modules, which results in the
newest WAR for the webapp
- go to the webapp project and tomcat7:deploy to it ..

Not as fast-development-mode as tomcat7:run (which doesnt include
installing the modules + WAR building), but this will do :-)

I may be too hopeful, but is this useful enough to be added as a new
feature of tomcat maven plugin ?
I imagine putting these aliases in the plugin's configuration in the
pom.xml ..

Thanks !

On Tue, Jul 31, 2012 at 12:54 AM, Olivier Lamy ol...@apache.org wrote:
Hi,
Not possible currently.
What is your use case ? those goals are for dev purpose.

2012/7/27 Albert Kam moonblade.w...@gmail.com:
I am currently using the snapshot version of tomcat maven plugin.
And i am using tomcat7:run and tomcat7:run-war-only (for webapps with
overlay) actively.

And the time has come for me to try out virtual host .. and as i
understand it, i have to configure the host, context, etc ..
But i've been using the embedded tomcat 'supplied' by the tomcat maven
plugin so far,

so i wonder if there's a way to configure virtual host on the embedded
tomcat ?

Or should i just forget embedded tomcat and setup an independent
tomcat i can configure freely ?

Thank you,
Albert

--
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)

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

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

-
To unsubscribe, e-mail:

Re: PDF Download problem tomcat = 7.0.27

I'm waiting for a better solution ...
Maybe should a sniffer pcap help in diagnosys?
Michele Masè

On Tue, Jul 31, 2012 at 5:28 PM, André Warnier a...@ice-sa.com wrote:

 Michele Mase' wrote:

 The only way to reproduce it is (for me) without the plugin; i'm sorry
 ...
 I haven't seen what happens using a sniffer, but the X in the apache's log
 file tells me that the client is aborting the session, I suspect a session
 reset could happen.
 And finally, following your suggestion, a F5 helped me:

 200Ok session:
 GET /test.pdf HTTP/1.1
 Accept: */*
 Accept-Encoding: gzip, deflate
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
 CLR 2.0.50727)
 Host: 
 installazioni-el6b.insiel.it:**8080http://installazioni-el6b.insiel.it:8080
 Connection: Keep-Alive
 Pragma: no-cache

 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Accept-Ranges: bytes
 ETag: W/3447866-1343391729000
 Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
 Content-Type: application/pdf
 Content-Length: 3447866
 Date: Tue, 31 Jul 2012 12:32:05 GMT

 206KO:
 GET /test.pdf HTTP/1.1
 Accept: */*
 Range: bytes=3446021-3447865, 475136-1792507
 Accept-Encoding: gzip, deflate
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
 CLR 2.0.50727)
 Host: 
 installazioni-el6b.insiel.it:**8080http://installazioni-el6b.insiel.it:8080
 Connection: Keep-Alive
 Pragma: no-cache

 HTTP/1.1 206 Partial Content
 Server: Apache-Coyote/1.1
 Accept-Ranges: bytes
 ETag: W/3447866-1343391729000
 Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
 Content-Type: multipart/byteranges;boundary=**CATALINA_MIME_BOUNDARY
 Date: Tue, 31 Jul 2012 12:32:20 GMT
 Content-Length: 1319458


 The above appears (to me) to be two correct request/response pairs.
 Even the 206, which is a normal response to the Range request as per
 here : 
 http://www.w3.org/Protocols/**rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

 We still don't know if/why the browser/client resets the connection, but
 it is not visible in the above exchange.
 Maybe inspecting the response body to the second request would provide a
 clue.

 It is also a bit of a mystery to me why the same browser would sometimes
 request the same resource in one go, and sometimes as byteranges.  But I
 don't know exactly how this part is supposed to work.
 Maybe it depends on which part of the PDF the user decides to display ?


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

Re: PDF Download problem tomcat = 7.0.27


Michele Mase' wrote:

I'm waiting for a better solution ...
Maybe should a sniffer pcap help in diagnosys?


Wireshark is your friend. It may at least show you when the client disconnects, and maybe 
why.  But if the problem is in the response body, I don't know if it will be very easy to 
find with a packet dump (and these responses are big).


Wait a bit.  Maybe someone else more knowledgeable will see something strange in those 
headers.


Another idea : the 206 response header contains a Content-Length header. According to 
the specs, this is supposed to be the total number of bytes which should be contained in 
the response body (before decoding it into parts).
Try to compare this, with what your Apache log tells you about the response size for the 
same request.
Careful when comparing : I believe that the response size, for Apache, includes the HTTP 
headers; while the Content-Length headers refers only to the response body, without the 
headers.




On Tue, Jul 31, 2012 at 5:28 PM, André Warnier a...@ice-sa.com wrote:


Michele Mase' wrote:


The only way to reproduce it is (for me) without the plugin; i'm sorry
...
I haven't seen what happens using a sniffer, but the X in the apache's log
file tells me that the client is aborting the session, I suspect a session
reset could happen.
And finally, following your suggestion, a F5 helped me:

200Ok session:
GET /test.pdf HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: 
installazioni-el6b.insiel.it:**8080http://installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: application/pdf
Content-Length: 3447866
Date: Tue, 31 Jul 2012 12:32:05 GMT

206KO:
GET /test.pdf HTTP/1.1
Accept: */*
Range: bytes=3446021-3447865, 475136-1792507
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 2.0.50727)
Host: 
installazioni-el6b.insiel.it:**8080http://installazioni-el6b.insiel.it:8080
Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: multipart/byteranges;boundary=**CATALINA_MIME_BOUNDARY
Date: Tue, 31 Jul 2012 12:32:20 GMT
Content-Length: 1319458



The above appears (to me) to be two correct request/response pairs.
Even the 206, which is a normal response to the Range request as per
here : 
http://www.w3.org/Protocols/**rfc2616/rfc2616-sec10.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

We still don't know if/why the browser/client resets the connection, but
it is not visible in the above exchange.
Maybe inspecting the response body to the second request would provide a
clue.

It is also a bit of a mystery to me why the same browser would sometimes
request the same resource in one go, and sometimes as byteranges.  But I
don't know exactly how this part is supposed to work.
Maybe it depends on which part of the PDF the user decides to display ?


--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@tomcat.**apache.orgusers-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: PDF Download problem tomcat = 7.0.27

2012-07-31 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 7/31/12 2:49 PM, André Warnier wrote:
 Michele Mase' wrote:
 I'm waiting for a better solution ... Maybe should a sniffer pcap
 help in diagnosys?
 
 Wireshark is your friend. It may at least show you when the client 
 disconnects, and maybe why.  But if the problem is in the response
 body, I don't know if it will be very easy to find with a packet
 dump (and these responses are big).
 
 Wait a bit.  Maybe someone else more knowledgeable will see
 something strange in those headers.
 
 Another idea : the 206 response header contains a Content-Length 
 header. According to the specs, this is supposed to be the total
 number of bytes which should be contained in the response body
 (before decoding it into parts). Try to compare this, with what
 your Apache log tells you about the response size for the same
 request. Careful when comparing : I believe that the response size,
 for Apache, includes the HTTP headers; while the Content-Length
 headers refers only to the response body, without the headers.

What's interesting to note is that the request specifies two separate
ranges:

Request
- ---
GET /test.pdf HTTP/1.1
Accept: */*
Range: bytes=3446021-3447865, 475136-1792507

...

Response
- 
HTTP/1.1 206 Partial Content
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/3447866-1343391729000
Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
Date: Tue, 31 Jul 2012 12:32:20 GMT
Content-Length: 1319458
(end of post)

There should probably be a chunk of the response with a Content-Length
of -(3446021-3447865)=1844 bytes and another one with Content-Length
of -(475136-1792507)=1317371 bytes, all packaged-up inside this single
response.

Can we get more of the data that you see?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAYMMIACgkQ9CaO5/Lv0PC3MQCfZcQ6Y6fka2miDK4yD5Uufp3K
VKEAoIilIDXuuqDSa1DYWQ/WgxEJYFHa
=qTvX
-END PGP SIGNATURE-

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

Re: PDF Download problem tomcat = 7.0.27

2012-07-31 Thread Jose María Zaragoza

2012/7/31 Michele Mase' michele.m...@gmail.com:
 I'm waiting for a better solution ...

One silly question, do you have try to reproduce this issue with an
upper version of PDF Library ? I know that you cannot to upgrade all
clients but we can to discard a bug in this plugin

And, do you have try with another browser, like Chrome ?  i know that
you cannot to ask your clients to change your browsers , but Chrome
has tools for develovers to monitoring the usage of network, headers,
etc.

Well, finally, they were two silly questions :-)

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

Re: PDF Download problem tomcat = 7.0.27

Tomorrow I'will try with wireshark hoping better results!

On Tue, Jul 31, 2012 at 9:23 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 André,

 On 7/31/12 2:49 PM, André Warnier wrote:
  Michele Mase' wrote:
  I'm waiting for a better solution ... Maybe should a sniffer pcap
  help in diagnosys?
 
  Wireshark is your friend. It may at least show you when the client
  disconnects, and maybe why.  But if the problem is in the response
  body, I don't know if it will be very easy to find with a packet
  dump (and these responses are big).
 
  Wait a bit.  Maybe someone else more knowledgeable will see
  something strange in those headers.
 
  Another idea : the 206 response header contains a Content-Length
  header. According to the specs, this is supposed to be the total
  number of bytes which should be contained in the response body
  (before decoding it into parts). Try to compare this, with what
  your Apache log tells you about the response size for the same
  request. Careful when comparing : I believe that the response size,
  for Apache, includes the HTTP headers; while the Content-Length
  headers refers only to the response body, without the headers.

 What's interesting to note is that the request specifies two separate
 ranges:

 Request
 - ---
 GET /test.pdf HTTP/1.1
 Accept: */*
 Range: bytes=3446021-3447865, 475136-1792507

 ...

 Response
 - 
 HTTP/1.1 206 Partial Content
 Server: Apache-Coyote/1.1
 Accept-Ranges: bytes
 ETag: W/3447866-1343391729000
 Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
 Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
 Date: Tue, 31 Jul 2012 12:32:20 GMT
 Content-Length: 1319458
 (end of post)

 There should probably be a chunk of the response with a Content-Length
 of -(3446021-3447865)=1844 bytes and another one with Content-Length
 of -(475136-1792507)=1317371 bytes, all packaged-up inside this single
 response.

 Can we get more of the data that you see?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlAYMMIACgkQ9CaO5/Lv0PC3MQCfZcQ6Y6fka2miDK4yD5Uufp3K
 VKEAoIilIDXuuqDSa1DYWQ/WgxEJYFHa
 =qTvX
 -END PGP SIGNATURE-

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

Re: PDF Download problem tomcat = 7.0.27

Since there are a lot of silly technicians that cannot utilize any browser
wxcept ie, and some people told me look, before the upgrade (was tomcat
7.0.16) all worked for me and now some pdf are ko, it must work with the
ancient configuration XP+IE+Acrobat9.
Other brosers, like firefox or other pdf viewers like foxit seem not have
the problem.
Michele Masè

On Tue, Jul 31, 2012 at 9:28 PM, Jose María Zaragoza
demablo...@gmail.comwrote:

 2012/7/31 Michele Mase' michele.m...@gmail.com:
  I'm waiting for a better solution ...

 One silly question, do you have try to reproduce this issue with an
 upper version of PDF Library ? I know that you cannot to upgrade all
 clients but we can to discard a bug in this plugin

 And, do you have try with another browser, like Chrome ?  i know that
 you cannot to ask your clients to change your browsers , but Chrome
 has tools for develovers to monitoring the usage of network, headers,
 etc.

 Well, finally, they were two silly questions :-)

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

Re: PDF Download problem tomcat = 7.0.27

2012-07-31 Thread Konstantin Kolinko

2012/7/31 Michele Mase' michele.m...@gmail.com:
 The only way to reproduce it is (for me) without the plugin; i'm sorry ...
 I haven't seen what happens using a sniffer, but the X in the apache's log
 file tells me that the client is aborting the session, I suspect a session
 reset could happen.
 And finally, following your suggestion, a F5 helped me:

 200Ok session:
 GET /test.pdf HTTP/1.1
 Accept: */*
 Accept-Encoding: gzip, deflate
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
 CLR 2.0.50727)
 Host: installazioni-el6b.insiel.it:8080
 Connection: Keep-Alive
 Pragma: no-cache

 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Accept-Ranges: bytes
 ETag: W/3447866-1343391729000
 Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
 Content-Type: application/pdf
 Content-Length: 3447866
 Date: Tue, 31 Jul 2012 12:32:05 GMT

 206KO:
 GET /test.pdf HTTP/1.1
 Accept: */*
 Range: bytes=3446021-3447865, 475136-1792507
 Accept-Encoding: gzip, deflate
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
 CLR 2.0.50727)
 Host: installazioni-el6b.insiel.it:8080
 Connection: Keep-Alive
 Pragma: no-cache

 HTTP/1.1 206 Partial Content
 Server: Apache-Coyote/1.1
 Accept-Ranges: bytes
 ETag: W/3447866-1343391729000
 Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
 Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
 Date: Tue, 31 Jul 2012 12:32:20 GMT
 Content-Length: 1319458


The Content-Length header in the above 206 response is not from Tomcat.

Tomcat's DefaultServlet does not calculate the whole size of the parts
and does not set content-length, and the file size is much more than
fits into the buffer.
So it would use  Transfer-Encoding: chunked  in its response and not
the one that you cited.
There must be some proxy in the way that buffers the data and sends
them as one response instead of chunks. HTTPD? Was there some option
in it that disables chunked encoding when interacting with IE?

I tried to reproduce this request locally with a telnet client, and
when I have local A/V software turned on, it interferes and re-chunks
the response into larger chunks.
If I turn the A/V off, I see Tomcat 7.0.29 responding in chunks of 2Kb
(0x2000 bytes) each, as expected.


Best regards,
Konstantin Kolinko

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

Re: PDF Download problem tomcat = 7.0.27

2012-07-31 Thread Jose María Zaragoza

 The Content-Length header in the above 206 response is not from Tomcat.

 Tomcat's DefaultServlet does not calculate the whole size of the parts
 and does not set content-length, and the file size is much more than
 fits into the buffer.
 So it would use  Transfer-Encoding: chunked  in its response and not
 the one that you cited.
 There must be some proxy in the way that buffers the data and sends
 them as one response instead of chunks. HTTPD? Was there some option
 in it that disables chunked encoding when interacting with IE?


Well, i don't know so much, but that doesn't have to do with chunked
encoding, but Partial Content support, right ?
And partial content is requested by client (IE) if Content-length is
very big ( I guess ... )
Maybe, IE requests a PDF file (GET) and  if it sees a Content-length
very big , cuts downloading and re-send a GET request with a range of
bytes.

Chrome looks to perform something like that behaviour

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

Re: PDF Download problem tomcat = 7.0.27