Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-31 Thread David Law

André,

regarding the Content-Transfer-Encoding header mentioned in:
http://www.w3.org/TR/SVGTiny12/mimereg.html

Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME):
http://tools.ietf.org/html/rfc2045

RFC 2616 (HTTP/1.1) states, here 19.4.5 No Content-Transfer-Encoding:
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Also, under RFC 2616 (HTTP/1.1) 19.4.4  19.4.6 respectively,
Content-Encoding  Transfer-Encoding are introduced.

Transfer-Encoding  Content-Transfer-Encoding are intended
for use in transmission only, so the data will arrive intact.
An example of such would be Base64:
http://en.wikipedia.org/wiki/Base64

I think we were right to choose Content-Encoding.

All the best,
DaveLaw

On 30/12/2013 01:28, David Law wrote:

Hi André,

thats exactly what the JIRA Request is about:
https://java.net/jira/browse/SERVLET_SPEC-86

We want a generic solution  not just something specific to *.svgz

Regarding the Content-Transfer-Encoding header,
I'm afraid that's beyond me.
Maybe Mark has an opinion on that?

Regards,
DaveLaw

On 30/12/2013 00:18, André Warnier wrote:

Mark Thomas wrote:

On 28/12/2013 21:36, David Law wrote:

I just tried this in DefaultServlet:

if (contentType.equals(image/svg+xml)
  path.toLowerCase().endsWith(.svgz)) {
response.addHeader(Content-Encoding, gzip);
}

Quick  dirty, but Works fine as proof-of-concept.
We just need a DefaultServlet expert to do the slow  clean stuff.


I'd suggest simply using a filter mapped to *.svgz for now.

I believe a generic solution to be best though, long-term. 
Something like:


That would be my preference but would require a change from the Servlet
EG. I'm not sure if adding a element to mime-mapping or adding a new
encoding-mapping element is the best solution. I created
https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add 
comments.




As a comment, I would like to add that the adding of a 
Content-Encoding header for certain data files served by Tomcat may 
be interesting for more types than just *.svgz files.
For example, in document-management or archive applications, it is 
interesting to store various types of documents on the server in an 
already-compressed format and serve them that way, yet have the 
client receive the information necessary to automatically uncompress 
the response content to handle the original format correctly, without 
having to use a specific servlet filter or document-retrieval servlet 
to do so.
The discussion about .svgz is equally applicable to all kinds of 
*.xxx.gz files for instance, where xxx may be PDF, MS-Office, plain 
text or whatever could be stored pre-compressed on the server. 
(Applications of the store once, retrieve many times model).



As another side-comment, there seems to exist an ambiguity/error in 
the following document : http://www.w3.org/TR/SVGTiny12/mimereg.html

In section Security considerations, it says :

quote

SVG documents may be transmitted in compressed form using gzip 
compression. For systems which employ MIME-like mechanisms, such as 
HTTP, this is indicated by the *Content-Transfer-Encoding header*; 
for systems which do not, ...


unquote
(emphasis mine)

but the HTTP specification in RFC 2616 does not have a 
Content-Transfer-Encoding header.
It has Content-Encoding and Transfer-Encoding, as two distinct 
headers with distinct meanings.



-
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: the acceptCount attribute not work like it's configuration

2013-12-31 Thread Mark Thomas
On 31/12/2013 02:01, 侯树成 wrote:
 Hi,
 Today, I find the acceptCount  of connector is not work like it's config.
 You can try it like this:
 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=2 maxThreads=1
 minSpareThreads=1/
 
 use LR or JMeter make more requests( 10) .  You will find that 5 requests
 will served correctly, others will be refused.
 
 When the acceptCount=3
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=3 maxThreads=1
 minSpareThreads=1/
 
  You will find that 7 requests will served correctly, others will be
 refused.
 
 
 When the acceptCount=4
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=4 maxThreads=1
 minSpareThreads=1/
 
  You will find that 9 requests will served correctly, others will be
 refused.
 
 Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?
 
 why the acceptCount is not work like it's configuration?
 
 Could you help me? Thank you.

With the information provided above, no.

I have already explained how maxConnections is enforced by Tomcat.

The behaviour you observe in your test will depend on the configuration
of the client (number of threads, timeouts, etc.) which you have failed
to provide.

Mark

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



Re: doe response auto commit when browser abort or close?

2013-12-31 Thread Mark Thomas
On 31/12/2013 07:53, 侯树成 wrote:
 Hi, I got an Exception like this:
 
 java.lang.IllegalStateException: Cannot call sendError() after the response
 has been committed
 
 
 I got it in following steps:
 1. Deploy a web app.
 2. request the app in browser, refresh the page when it not response
 fully(or close it when the page not response correctly)
 3. get the exception
 
 
 the exception was throw in blow code:
 
 class OutputBuffer
  public void realWriteBytes(byte buf[], int off, int cnt) {
  .
 coyoteResponse.doWrte(outputChunk);   //it will throw
 java.io.IOException: An established connection was aborted
   //by the software in your host
 machine
 } catch (IOException e) {
 // An IOException on a write is almost always due to
 // the remote client aborting the request.  Wrap this
 // so that it can be handled better by the error dispatcher.
 throw new ClientAbortException(e);  // it will handled by
 outter code.But now the commit equals true when sendError method execute,
 so
//IllegalStateException will throw.
 }
 }
 
 Does the response will set commit = true when the client close or abort?

No.

Mark

 In source code, I just find the flush method or close method will set
 commit = true, others was correct request/response lifecycle.
 
 Thanks in advance.
 


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



Re: the acceptCount attribute not work like it's configuration

2013-12-31 Thread 侯树成
Oh, everything is default in server.xml except Connector configuration.
I have already explained how maxConnections is enforced by Tomcat. Where?
When? I'm sorry, I havn't know it.
the configuration of the client (number of threads, timeouts, etc.)   --
just need a simple web app, in the servlet you can sleep 60s.

Thank you for your reply.



2013/12/31 Mark Thomas ma...@apache.org

 On 31/12/2013 02:01, 侯树成 wrote:
  Hi,
  Today, I find the acceptCount  of connector is not work like it's config.
  You can try it like this:
  Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 acceptCount=2 maxThreads=1
  minSpareThreads=1/
 
  use LR or JMeter make more requests( 10) .  You will find that 5
 requests
  will served correctly, others will be refused.
 
  When the acceptCount=3
 Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 acceptCount=3 maxThreads=1
  minSpareThreads=1/
 
   You will find that 7 requests will served correctly, others will be
  refused.
 
 
  When the acceptCount=4
 Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 acceptCount=4 maxThreads=1
  minSpareThreads=1/
 
   You will find that 9 requests will served correctly, others will be
  refused.
 
  Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?
 
  why the acceptCount is not work like it's configuration?
 
  Could you help me? Thank you.

 With the information provided above, no.

 I have already explained how maxConnections is enforced by Tomcat.

 The behaviour you observe in your test will depend on the configuration
 of the client (number of threads, timeouts, etc.) which you have failed
 to provide.

 Mark

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




Single error page for multiple web applications

2013-12-31 Thread Maarten van Hulsentop
Hello,

We are using Tomcat to host a number of web applications as a uniform
solution. We trying to implement something that seems to be an odd
requirement, even though it is really a use case for us.

We would like to define a single [default] error page for all web
applications residing on this Tomcat instance. After some experimentation
and googling around, it seems that there is no clear-cut solution for this.
I see a few options;

- Let the global conf/web.xml define error pages for all web applications
at once. However these are always relative to the web application context,
and require every web application to pack the error pages again, which is a
duplicate of resources and defeats the DRY principle.
- An Error reporting valve can be implemented to handle error pages. Simply
extend ErrorReportValve delivered from Tomcat and implement the report()
method. But then how should this report method behave?
1-  It could build up a HTML page from java code directly (as is being done
in the Tomcat default implementation of the ErrorReportValve). The downside
of this would be that it is not possible to style the page afterwards.
2-  It could fetch the HTML page from a location specified in configuration
(system property or otherwise) and stream it to the client. But is it
possible to have dynamic behavior in that case (jsp behavior). I think we
would need a RequestDispatcher for that and that is supposed to be in
context i presume.
3-  It could fetch the ROOT context (which has to be crossContext=true then
i assume) and delegate the handling of errors to a page in the root
context. This one would have my preference, as it allows the configuration
of a single error page, while trying to stick (mimic) as much of the normal
J2EE behavior as possible. But it also seems to be the most tricky one.
Also, i am not sure on the crossContext setting. Documentation points out
that it should not be set on security conscious environments. My experience
is that security is always important, so does this make it a no-no or is
this a theoretical security risk?

Please share your opinions about this, things i missed, or (even better!)
your solution :)

Thank you in advance!
Regards,

Maarten van Hulsentop


JSVC error

2013-12-31 Thread vicky
Hi,
 
I  have configured the below in my tomcat 7.0.39 startup script  when 
executing this script I 'm getting segmentation error(detailed error mentioned 
below)
 
Please suggest how to fix this.
 
+ start up script ++
CATALINA_BASE=/root/test/tomcattest
CATALINA_HOME=/root/home/apache-tomcat-7.0.39
    cd $CATALINA_BASE
    ./bin/jsvc  \
    -cp $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar 
\
    -outfile $CATALINA_BASE/logs/catalina.out \
    -errfile $CATALINA_BASE/logs/catalina.err \
    -Dcatalina.home=$CATALINA_HOME \
    -pidfile $CATALINA_PID \
    -Dcatalina.base=$CATALINA_BASE \
    -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
    -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
    org.apache.catalina.startup.Bootstrap start
++

 ERROR 
++=
./startdaemon.sh: line 13:  7429 Segmentation fault  (core dumped) 
./bin/jsvc -cp 
$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile 
$CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err 
-Dcatalina.home=$CATALINA_HOME -pidfile $CATALINA_PID 
-Dcatalina.base=$CATALINA_BASE 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
org.apache.catalina.startup.Bootstrap start

+++

Thanks
Vickyy


Re: Single error page for multiple web applications

2013-12-31 Thread Serge Fonville
Hello Maarten,

When I was in the same boat, I found
http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand
http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful.

I found these by googling
https://www.google.nl/?gws_rd=crei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+pagesafe=off

HTH

Kind regards/met vriendelijke groet,

Serge Fonville

http://www.sergefonville.nl


2013/12/31 Maarten van Hulsentop maar...@vanhulsentop.nl

 Hello,

 We are using Tomcat to host a number of web applications as a uniform
 solution. We trying to implement something that seems to be an odd
 requirement, even though it is really a use case for us.

 We would like to define a single [default] error page for all web
 applications residing on this Tomcat instance. After some experimentation
 and googling around, it seems that there is no clear-cut solution for this.
 I see a few options;

 - Let the global conf/web.xml define error pages for all web applications
 at once. However these are always relative to the web application context,
 and require every web application to pack the error pages again, which is a
 duplicate of resources and defeats the DRY principle.
 - An Error reporting valve can be implemented to handle error pages. Simply
 extend ErrorReportValve delivered from Tomcat and implement the report()
 method. But then how should this report method behave?
 1-  It could build up a HTML page from java code directly (as is being done
 in the Tomcat default implementation of the ErrorReportValve). The downside
 of this would be that it is not possible to style the page afterwards.
 2-  It could fetch the HTML page from a location specified in configuration
 (system property or otherwise) and stream it to the client. But is it
 possible to have dynamic behavior in that case (jsp behavior). I think we
 would need a RequestDispatcher for that and that is supposed to be in
 context i presume.
 3-  It could fetch the ROOT context (which has to be crossContext=true then
 i assume) and delegate the handling of errors to a page in the root
 context. This one would have my preference, as it allows the configuration
 of a single error page, while trying to stick (mimic) as much of the normal
 J2EE behavior as possible. But it also seems to be the most tricky one.
 Also, i am not sure on the crossContext setting. Documentation points out
 that it should not be set on security conscious environments. My experience
 is that security is always important, so does this make it a no-no or is
 this a theoretical security risk?

 Please share your opinions about this, things i missed, or (even better!)
 your solution :)

 Thank you in advance!
 Regards,

 Maarten van Hulsentop



Re: JSVC error

2013-12-31 Thread Konstantin Kolinko
2013/12/31 vicky vicky007aggar...@yahoo.co.in:
 Hi,

 I  have configured the below in my tomcat 7.0.39 startup script  when 
 executing this script I 'm getting segmentation error(detailed error 
 mentioned below)

 Please suggest how to fix this.

 + start up script ++
 CATALINA_BASE=/root/test/tomcattest
 CATALINA_HOME=/root/home/apache-tomcat-7.0.39
 cd $CATALINA_BASE
 ./bin/jsvc  \
 -cp 
 $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \
 -outfile $CATALINA_BASE/logs/catalina.out \
 -errfile $CATALINA_BASE/logs/catalina.err \
 -Dcatalina.home=$CATALINA_HOME \
 -pidfile $CATALINA_PID \
 -Dcatalina.base=$CATALINA_BASE \
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
 
 -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
 org.apache.catalina.startup.Bootstrap start
 ++

  ERROR 
 ++=
 ./startdaemon.sh: line 13:  7429 Segmentation fault  (core dumped) 
 ./bin/jsvc -cp 
 $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile 
 $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err 
 -Dcatalina.home=$CATALINA_HOME -pidfile $CATALINA_PID 
 -Dcatalina.base=$CATALINA_BASE 
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
 -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
 org.apache.catalina.startup.Bootstrap start

 +++


1. Did you tell jsvc where your Java is?
You can use either -home argument or JAVA_HOME environment variable.

http://commons.apache.org/proper/commons-daemon/jsvc.html

2. You have not defined the value of CATALINA_PID variable.

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



Re: JSVC error

2013-12-31 Thread vicky
Even after defining the $CATALINA_PID  $JAVA_HOME variable , i'm still the 
getting segmentation error(detailed error mentioned below)

++
bin/startdaemon.sh: line 13:  4402 Segmentation fault  (core dumped) 
./bin/jsvc -cp 
$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile 
$CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err 
-Dcatalina.home=$CATALINA_HOME -pidfile /root/test/tomcattest 
-Dcatalina.base=$CATALINA_BASE 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
org.apache.catalina.startup.Bootstrap start
 

Thanks
Vicky

From: Konstantin Kolinko knst.koli...@gmail.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Tuesday, 31 December 2013 4:03 PM
Subject: Re: JSVC error


2013/12/31 vicky vicky007aggar...@yahoo.co.in: 

 Hi,

 I  have configured the below in my tomcat 7.0.39 startup script  when 
 executing this script I 'm getting segmentation error(detailed error 
 mentioned below)

 Please suggest how to fix this.

 + start up script ++
 CATALINA_BASE=/root/test/tomcattest
 CATALINA_HOME=/root/home/apache-tomcat-7.0.39
    cd $CATALINA_BASE
    ./bin/jsvc  \
        -cp 
$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \
        -outfile $CATALINA_BASE/logs/catalina.out \
        -errfile $CATALINA_BASE/logs/catalina.err \
        -Dcatalina.home=$CATALINA_HOME \
        -pidfile $CATALINA_PID \
        -Dcatalina.base=$CATALINA_BASE \
        -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
        -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
\
        org.apache.catalina.startup.Bootstrap start
 ++

  ERROR 
 ++=
 ./startdaemon.sh: line 13:  7429 Segmentation fault      (core dumped) 
 ./bin/jsvc -cp 
 $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile 
 $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err 
 -Dcatalina.home=$CATALINA_HOME -pidfile $CATALINA_PID 
 -Dcatalina.base=$CATALINA_BASE 
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
 -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties 
 org.apache.catalina.startup.Bootstrap start

 +++


1. Did you tell jsvc where your Java is?
You can use either -home argument or JAVA_HOME environment variable.

http://commons.apache.org/proper/commons-daemon/jsvc.html

2. You have not defined the value of CATALINA_PID variable.

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

Re: the acceptCount attribute not work like it's configuration

2013-12-31 Thread Mark Thomas
On 31/12/2013 09:42, 侯树成 wrote:
 Oh, everything is default in server.xml except Connector configuration.

Yes, I can read thanks.

 I have already explained how maxConnections is enforced by Tomcat. Where?
 When? I'm sorry, I havn't know it.

You replied to my explanation so I suggest you go back and re-read the
thread for your previous question.

 the configuration of the client (number of threads, timeouts, etc.)   --
 just need a simple web app, in the servlet you can sleep 60s.

None of which answers my questions about the client configuration.

 Thank you for your reply.

Mark


 
 
 
 2013/12/31 Mark Thomas ma...@apache.org
 
 On 31/12/2013 02:01, 侯树成 wrote:
 Hi,
 Today, I find the acceptCount  of connector is not work like it's config.
 You can try it like this:
 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=2 maxThreads=1
 minSpareThreads=1/

 use LR or JMeter make more requests( 10) .  You will find that 5
 requests
 will served correctly, others will be refused.

 When the acceptCount=3
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=3 maxThreads=1
 minSpareThreads=1/

  You will find that 7 requests will served correctly, others will be
 refused.


 When the acceptCount=4
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=4 maxThreads=1
 minSpareThreads=1/

  You will find that 9 requests will served correctly, others will be
 refused.

 Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?

 why the acceptCount is not work like it's configuration?

 Could you help me? Thank you.

 With the information provided above, no.

 I have already explained how maxConnections is enforced by Tomcat.

 The behaviour you observe in your test will depend on the configuration
 of the client (number of threads, timeouts, etc.) which you have failed
 to provide.

 Mark

 -
 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: Java to JavaScript RMI framework available.

2013-12-31 Thread Leon Rosenberg
Hello Igor,

this looks really promising, I will take a deeper look in next year ;-)

Btw, Happy New Year to Everyone ;-)

Leon


On Tue, Dec 31, 2013 at 1:55 AM, Igor Urisman igor.uris...@gmail.comwrote:

 Folks,

 I needed to write this for something I am working on and thought there
 might be a wider audience for it.
 Tomcat 8 supports standard compliant Websockets, which provide convenient
 asynchronous full-duplex
 server to client data transport. The framework I am offering builds on top
 of that a feature rich remote
 method invocation paradigm.  Please check it out.

 https://github.com/iurisman/FERMI
 Apache 2.0 license.

 Happy coding.
 Igor.



Re: Single error page for multiple web applications

2013-12-31 Thread Maarten van Hulsentop
Hello Serge,

Thank you for your reply. This option seems to be similar to the first
thing i tried, editing conf/web.xml. As is suggested in
http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcat

But contrary to what's stated in the stackoverlow message, this does not
work if the error occours in the context of another web application.
The following issue description is similar to mine;
http://anthonyjdev.blogspot.nl/2012/09/custom-error-page-for-all-apps-in-tomcat.html
In this case, even if the location is defined in conf/web.xml (global), the
error pages are being searched for in the context of the web application
that issued the error. In strict J2EE sense, i do understand that
reasoning. That's not what i want though ;)

If i am wrong about the understanding of all of this, please correct me.
But i just tried that stackoverlow approach again and still it seems to be
tied to the webapp that issues the error.

Thank you,

Regards,

Maarten

.





2013/12/31 Serge Fonville serge.fonvi...@gmail.com

 Hello Maarten,

 When I was in the same boat, I found

 http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand
 http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful.

 I found these by googling

 https://www.google.nl/?gws_rd=crei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+pagesafe=off

 HTH

 Kind regards/met vriendelijke groet,

 Serge Fonville

 http://www.sergefonville.nl


 2013/12/31 Maarten van Hulsentop maar...@vanhulsentop.nl

  Hello,
 
  We are using Tomcat to host a number of web applications as a uniform
  solution. We trying to implement something that seems to be an odd
  requirement, even though it is really a use case for us.
 
  We would like to define a single [default] error page for all web
  applications residing on this Tomcat instance. After some experimentation
  and googling around, it seems that there is no clear-cut solution for
 this.
  I see a few options;
 
  - Let the global conf/web.xml define error pages for all web applications
  at once. However these are always relative to the web application
 context,
  and require every web application to pack the error pages again, which
 is a
  duplicate of resources and defeats the DRY principle.
  - An Error reporting valve can be implemented to handle error pages.
 Simply
  extend ErrorReportValve delivered from Tomcat and implement the report()
  method. But then how should this report method behave?
  1-  It could build up a HTML page from java code directly (as is being
 done
  in the Tomcat default implementation of the ErrorReportValve). The
 downside
  of this would be that it is not possible to style the page afterwards.
  2-  It could fetch the HTML page from a location specified in
 configuration
  (system property or otherwise) and stream it to the client. But is it
  possible to have dynamic behavior in that case (jsp behavior). I think we
  would need a RequestDispatcher for that and that is supposed to be in
  context i presume.
  3-  It could fetch the ROOT context (which has to be crossContext=true
 then
  i assume) and delegate the handling of errors to a page in the root
  context. This one would have my preference, as it allows the
 configuration
  of a single error page, while trying to stick (mimic) as much of the
 normal
  J2EE behavior as possible. But it also seems to be the most tricky one.
  Also, i am not sure on the crossContext setting. Documentation points out
  that it should not be set on security conscious environments. My
 experience
  is that security is always important, so does this make it a no-no or is
  this a theoretical security risk?
 
  Please share your opinions about this, things i missed, or (even better!)
  your solution :)
 
  Thank you in advance!
  Regards,
 
  Maarten van Hulsentop
 



Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/31/13, 2:52 AM, David Law wrote:
 these are 2 completely different issues.
 
 svgz's should be served with the correct encoding (gzip) as
 required by the W3C SVG standard.  ALWAYS. 
 http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers That
 means, files with the extension .svgz will be served, as they are,
 with the Content-Encoding header gzip. This is
 performance-neutral.

The correct encoding is debatable: one can argue that web servers
shouldn't be adding the Content-Encoding:gzip to resources that the
server itself did not gzip. If web servers were to take .gz files from
the disk and set Content-Encoding:gzip, then the client would
decompress the data upon receipt instead of storing the compressed
bytes sent by the server originally. That has the effect of mutating
the original resource form the perspective of the client.

In this case, the SVG standard is asking SVG servers (presumably
distinct from web servers) to behave differently than originally
expected. I think there's some wiggle-room here and its not as
black-and-white as you propose.

 The Patch is something completely different: it serves a file
 with a particular extension, say *.XXX, from *.XXX.gz, if present.
 SOMETIMES (depending on the Servlet gzip-parameter). This will add
 a certain overhead, server-side, for EVERY FILE served. (because
 if present implies a resources lookup)

True, but irrelevant. This is no different from serving any file from
a web server.

 svgz's have the extension .svgz, not .svg.gz or .svgz.gz or
 anything else for that matter, so The Patch will not have any
 effect, and should not, for that matter.

The extension is not terribly relevant, other than its what you chose
to check for. In order to serve .svgz files in the way you want, a
simple Filter can be used -- and markt already gave you the code to do so.

Your original message said Any chance of getting this [feature] at
long last? You make it seem like Tomcat is refusing to implement some
crucial capability hat only the container can provide. This is not
true for two reasons: first, it is not necessary for Tomcat to
implement this - it can be done trivially by the web application;
second, there is already a component in Tomcat that can be used to do
this (bug 54095) with a bit of a tweak -- looking for filenames other
than *.gz.

In your case, it probably makes sense to simply use Mark's Filter
until the Tomcat committers decide what to do about this case. Perhaps
an example Filter is the best thing to do here since it's a fairly
specific use case and definitely would result in surprising behavior
to many people if used by default. It's also clear there is room for
improvement to Philippe's initial patch.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF
6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt
b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02
oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui
C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO
ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6
WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG
VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc
OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc
yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml
C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS
FGKrbQ7zojR3wVHhGGlH
=WjKV
-END PGP SIGNATURE-

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



Re: the acceptCount attribute not work like it's configuration

2013-12-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/31/13, 6:11 AM, Mark Thomas wrote:
 On 31/12/2013 09:42, 侯树成 wrote:
 Oh, everything is default in server.xml except Connector
 configuration.
 
 Yes, I can read thanks.
 
 I have already explained how maxConnections is enforced by
 Tomcat. Where? When? I'm sorry, I havn't know it.
 
 You replied to my explanation so I suggest you go back and re-read
 the thread for your previous question.
 
 the configuration of the client (number of threads, timeouts,
 etc.)   -- just need a simple web app, in the servlet you can
 sleep 60s.
 
 None of which answers my questions about the client configuration.

You might want to take a look at 侯树成's previous message under a
different thread where he gives some details about server behavior
which sounds odd to me:

http://markmail.org/message/zvmxuagop7xiqinm

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwtgoAAoJEBzwKT+lPKRYhhcQAKDHm3x+tQoK5D23J0jL+C5g
KPI66/vIUZc+B6ilplZpVU8Zp9p4Rd8e+0uaaofC1LXq2048sbnxGah8rpoTR7EK
vPeucO5XsjEE5UjxouZt+qreFI08oaQN278m6dGRp37Q+KkV7Z/oU5TJUxA1CtR6
NaCXFfDG9mpu1qQZrGFKBrXVYkljxQF0q3TZn++MLeqHmmdoIkoDxbVgZSewHAwc
KPE+V23ZLYkyZ3liphOT36gDdC6YQR0P4tLxPUoKEZ1jWs3YoZP0IgJaEjd0ptmz
yIxQkOnmEsxPSbRzUHJaC+6PE3iQ2U3p5KHGR2AGFAuTnPCMItU5DatMnxgOzqaz
e4lYMkPwqY6hcksEY3nf9489GN2LYlrsFy0s5YtR7WsXZ9GcloIM1YnJOKoMPIvo
j8gztl6lEchTx5P5z+1eMJHvo2HMhkqtQGWjsF0r/rgduY17pccV5B85JSzH0mcq
er6btMNWMyMTAQqoP2u4Xbq0EoNp2LM9rmbKBAO0G8wdf9k3tQ5Mb9AsGv9ig11k
izmQkLSsw2hcOJpriyceIn2H320rzsKPxZ88MYaNebNyCeaYmjjOzBO+KxFIW6w5
b6oW+O8Pf3SloGxRmLqsNbPvDLs3/X1iBF3yJu5xLSGnUTjvjZZB87UlLd6H6xbQ
o2IeICyu0Bxa+Kkl7lBN
=oRbc
-END PGP SIGNATURE-

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



Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-31 Thread André Warnier

David Law wrote:

André,

regarding the Content-Transfer-Encoding header mentioned in:
http://www.w3.org/TR/SVGTiny12/mimereg.html

Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME):
http://tools.ietf.org/html/rfc2045

RFC 2616 (HTTP/1.1) states, here 19.4.5 No Content-Transfer-Encoding:
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Also, under RFC 2616 (HTTP/1.1) 19.4.4  19.4.6 respectively,
Content-Encoding  Transfer-Encoding are introduced.

Transfer-Encoding  Content-Transfer-Encoding are intended
for use in transmission only, so the data will arrive intact.
An example of such would be Base64:
http://en.wikipedia.org/wiki/Base64

I think we were right to choose Content-Encoding.



I agree.

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



Re: the acceptCount attribute not work like it's configuration

2013-12-31 Thread Mark Thomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31/12/2013 14:43, Christopher Schultz wrote:
 Mark,
 
 On 12/31/13, 6:11 AM, Mark Thomas wrote:
 On 31/12/2013 09:42, 侯树成 wrote:
 Oh, everything is default in server.xml except Connector 
 configuration.
 
 Yes, I can read thanks.
 
 I have already explained how maxConnections is enforced by 
 Tomcat. Where? When? I'm sorry, I havn't know it.
 
 You replied to my explanation so I suggest you go back and
 re-read the thread for your previous question.
 
 the configuration of the client (number of threads, timeouts, 
 etc.)   -- just need a simple web app, in the servlet you
 can sleep 60s.
 
 None of which answers my questions about the client
 configuration.
 
 You might want to take a look at 侯树成's previous message under a 
 different thread where he gives some details about server behavior 
 which sounds odd to me:
 
 http://markmail.org/message/zvmxuagop7xiqinm

I have looked at it and, again, the expected behaviour depends on the
client configuration which has yet to be provided. I do not intend
wasting my time reverse engineering possible client configurations
(threads, requests per thread, timeouts, etc) that could lead to the
stated results. The OP needs to provide the requested information.
I'll add that the longer they drag their feet that the more likely my
response is going to be working as designed rather than a full
explanation.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSwtz2AAoJEBDAHFovYFnnSYkP/iWsuQ3PpjGaeV39aZIsbVJH
HipTHfXU2dplPS5mag4Pp+m/HBnSK8LBAnERng54QEzJO28P7S3Ma7umZCvP0fWf
4usGDBs9fYauRXUNMUijMMY+9vaTc04e06tIUNPrR1dJnFwMnR2c8MBZn1APbD1d
P4QNBultCUBoLy2B/wB4eahlqWkCc6ferdE75jBlNdux8IOnEYA6kW0NnEWg9UbD
1mkh9do4PBXcqza50RRg5xa8P8EmlBcrlnWQvqz9Q+pouWNYaZkqiQ1mzP7r1gpI
qtlngswkl8O1fu2vpa7sgmNaE1RIR/7F6Lg5LmR+bFAvkV0FEvEM/kLn7TIbY+zd
3qfVj8HvnEO8LVSITTPJlSBpEJRLY7LFPu6mR95lMDoEOAFQZHVz8pbSrydtSXYH
0A5ejpPgFdlJS5Rs4Fd0ZwSZd0Xd0DZHFhCIl3e1rzEGf3L+gtm7klAZvDODRD0z
8uz+dDrMiYA9YJ0bKmO2J2NBXeWcJZ4DYuiXMrmSUpOaLjJInPc0DgIKRBM+D/4I
UjuvEaYpf9GBKmiGL2qjhDxj9nXsl6JnPO6LBBDeUVXE8HD3q3ECUq7S09tTIgSx
4eVinWsjUIz0O/2JEBRVx+mOitNkbxcmMUdxTCoMVK9Bfv1xDmGPp9T651sihU0I
e9fxdbbDb70SjsvI4qq+
=H0hG
-END PGP SIGNATURE-

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



Re: JSVC error

2013-12-31 Thread André Warnier

vicky wrote:

Even after defining the $CATALINA_PID  $JAVA_HOME variable , i'm still the 
getting segmentation error(detailed error mentioned below)



In my experience, a segmentation fault often occurs when the *binary* that you are 
trying to run, is not made for the platform on which you are trying to run it.
For example, you try to use under Solaris a binary made for Linux; or trying to run a 
64-bit binary on a 32-bit platform.  Stuff of that kind.

So, are you sure that the jsvc that you're using matches your platform ?
What about file (path_to)/jsvc ? what does it say ?


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



Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-31 Thread David Law

Chris,

there's nothing to debate: the standard says svgz's need
Content-Encoding: gzip
so thats what we have to do.

At this rate, we'll never get the Internet finished by Easter...

Happy New Year,
DaveLaw

On 31/12/2013 15:23, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/31/13, 2:52 AM, David Law wrote:

these are 2 completely different issues.

svgz's should be served with the correct encoding (gzip) as
required by the W3C SVG standard.  ALWAYS.
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers That
means, files with the extension .svgz will be served, as they are,
with the Content-Encoding header gzip. This is
performance-neutral.

The correct encoding is debatable: one can argue that web servers
shouldn't be adding the Content-Encoding:gzip to resources that the
server itself did not gzip. If web servers were to take .gz files from
the disk and set Content-Encoding:gzip, then the client would
decompress the data upon receipt instead of storing the compressed
bytes sent by the server originally. That has the effect of mutating
the original resource form the perspective of the client.

In this case, the SVG standard is asking SVG servers (presumably
distinct from web servers) to behave differently than originally
expected. I think there's some wiggle-room here and its not as
black-and-white as you propose.


The Patch is something completely different: it serves a file
with a particular extension, say *.XXX, from *.XXX.gz, if present.
SOMETIMES (depending on the Servlet gzip-parameter). This will add
a certain overhead, server-side, for EVERY FILE served. (because
if present implies a resources lookup)

True, but irrelevant. This is no different from serving any file from
a web server.


svgz's have the extension .svgz, not .svg.gz or .svgz.gz or
anything else for that matter, so The Patch will not have any
effect, and should not, for that matter.

The extension is not terribly relevant, other than its what you chose
to check for. In order to serve .svgz files in the way you want, a
simple Filter can be used -- and markt already gave you the code to do so.

Your original message said Any chance of getting this [feature] at
long last? You make it seem like Tomcat is refusing to implement some
crucial capability hat only the container can provide. This is not
true for two reasons: first, it is not necessary for Tomcat to
implement this - it can be done trivially by the web application;
second, there is already a component in Tomcat that can be used to do
this (bug 54095) with a bit of a tweak -- looking for filenames other
than *.gz.

In your case, it probably makes sense to simply use Mark's Filter
until the Tomcat committers decide what to do about this case. Perhaps
an example Filter is the best thing to do here since it's a fairly
specific use case and definitely would result in surprising behavior
to many people if used by default. It's also clear there is room for
improvement to Philippe's initial patch.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF
6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt
b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02
oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui
C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO
ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6
WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG
VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc
OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc
yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml
C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS
FGKrbQ7zojR3wVHhGGlH
=WjKV
-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



max_packet_size for data in mod_jk

2013-12-31 Thread frenchc44
Due to large payloads, we wanted to increase the max_packet size of the
mod_jk/ajp layer in order to see if it will help with performance. However,
it appears the max_packet_size for non- header requests is capped at 8192
bytes despite the documentation stating that it should be 65536. I am using
mod_jk version 1.2.31 

[Tue Dec 31 11:54:09 2013][12492:12640] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1145): sending to ajp13
pos=4 len=8192 max=16384

Here is some code from jk_ajp_common.c that sets the max size but appears to
ignore the max_packet_size...

Line 1708:  if (ae-left_bytes_to_send  0) {
int len = AJP13_MAX_SEND_BODY_SZ;
if (ae-left_bytes_to_send 
(jk_uint64_t)AJP13_MAX_SEND_BODY_SZ) {
len = (int)ae-left_bytes_to_send;
}

Any help would be much appreciated. 



--
View this message in context: 
http://tomcat.10.x6.nabble.com/max-packet-size-for-data-in-mod-jk-tp5009929.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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



Re: Single error page for multiple web applications

2013-12-31 Thread Leo Donahue
On Dec 31, 2013 3:15 AM, Maarten van Hulsentop maar...@vanhulsentop.nl
wrote:

 Hello,

 We are using Tomcat to host a number of web applications as a uniform
 solution. We trying to implement something that seems to be an odd
 requirement, evh it is really a use case for us.

 We would like to define a single [default] error page for all web
 applications residing on this Tomcat instance. After some experimentation
 and googling around, it seems that there is no clear-cut solution for
this.
 I see a few options;

 - Let the global conf/web.xml define error pages for all web applications
 at once. However these are always relative to the web application context,
 and require every web application to pack the error pages again, which is
a
 duplicate of resources and defeats the DRY principle.

I asked a question similar to this a while back regarding JSF templates.

If you pick a location to share this resource among all web apps, then your
web apps aren't self contained.

The solution is in your build / deploy process.

If you want to ignore that advice, Tomcat 8 now has webAppMount, if want to
go there.  I still haven't had a chance to explore that option.

Leo