subject:"Tomcat 8.0.15"

Re: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token

2017-01-10 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Abhishek,

On 1/10/17 8:03 AM, Kumar, Abhishek (IT Information Services ) wrote:
> Hi Peter,
> 
> Thank You!
> 
> So, the solution would be to switch to the upgraded version for
> this fix?

You could also completely remove access to the manager application
from untrusted IP addresses/ranges. IIRC CSRF tokens are only
generated once the user has been allowed to access the application. So
using e.g. RemoteAddressFilter before CSRF filter should protect
against an unauthenticated attacker from gaining a CSRF token.

But your version of Tomcat is quite old (more than 2 years out of
date), so upgrading should be on your short list of things to do.

http://tomcat.apache.org/security-8.html

- -chris

> -Original Message- From: Kreuser, Peter
> [mailto:pkreu...@airplus.com] Sent: Tuesday, January 10, 2017 5:25
> PM To: Tomcat Users List <users@tomcat.apache.org> Subject: AW:
> Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token
> 
> Hi Abishek,
> 
>> -Ursprüngliche Nachricht- Von: Kumar, Abhishek (IT
>> Information Services )
>> [mailto:abhishek.kum...@originenergy.com.au] Gesendet: Dienstag,
>> 10. Januar 2017 12:17 An: users@tomcat.apache.org Betreff:
>> Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token
>> 
>> 
>> Hi,
>> 
>> The Apache Tomcat web server running on the Load balancer is
>> affected by an information disclosure vulnerability in the index
>> page of the Manager and Host Manager applications. An
>> unauthenticated attacker can exploit this vulnerability to obtain
>> a valid cross-site request forgery (CSRF) token during the
>> redirect issued when requesting /manager/ or /host-manager/. This
>> token can be utilized by an attacker to construct a CSRF attack.
>> 
>> This is a Vulnerability issue with Tomcat 8.0.15.
>> 
>> We have this version of Tomcat installed in our Servers.
>> 
>> As suggested by Tomcat, this has been addressed and fixed after
>> 8.0.32 versions.
>> 
>> Restrict access to the /manager URL from unauthorised IP
>> addresses by implementing access control lists that only permit
>> authorised management stations or subnets. For more information,
>> see:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org
_security-2D8.html-23Fixed-5Fin-5FApache-5FTomcat-5F8.0.32=DgIFAg=Zg
VRmm3mf2P1-XDAyDsu4A=-JJsXOks_2Pd13691jEHA6PBSyPcGzblOMm00qdlxbs=54n
d4qu7eMUZgW9FFIX2Q9G2FdQGJ69mCZu7VvFyN0s=y_OfZJOm3x6d8KgLtJS6flhRUDt_I
8Aqk6kymbu3u2k=
>>
>>
>>
>> 
But, We do not want to upgrade the Tomcat right now.
>> 
>> Is there a way to implement this fix in our current Tomcat
>> Version.
>> 
>> 
>> Kind Regards, Abhishek Kumar
>> 
>> Note: This email, including any attachments, is confidential. If
>> you have received this email in error, please advise the sender
>> and delete it and all copies of it from your system. If you are
>> not the intended recipient of this email, you must not use,
>> print, distribute, copy or disclose its content to anyone
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> from a security standpoint there is no way around updating.
> 
> Specifically the CSRF attack is executed from the client, so
> whoever is at one of the authorized management stations will be
> executing the CSRF requests.
> 
> Aside from this one vulnerability all versions up to the current
> 8.0.40 fix a whole load of flaws. So whenever you restrict access
> to the management console (via RemoteAddrValve), all other
> vulnerabilities that are more than Info disclosures will still
> persist.
> 
> Best regards
> 
> Peter
> 
> 
> Peter Kreuser AirPlus International Security Officer - Application
> Development
> 
> -
>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYdUNLAAoJEBzwKT+lPKRYZ80P/3DNa4kW6z8cB1sdmm6GUK8O
Y7f0uzEYIIlirTqy091taJI7eH3jXpURtA2gJMy7LXFfTLkLFGOiM4FqPZdSQy

RE: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token

2017-01-10 Thread Kumar, Abhishek (IT Information Services )

Hi Peter,

Thank You!

So, the solution would be to switch to the upgraded version for this fix?

Thanks and Regards,
Abhishek Kumar

-Original Message-
From: Kreuser, Peter [mailto:pkreu...@airplus.com] 
Sent: Tuesday, January 10, 2017 5:25 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: AW: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token

Hi Abishek,
 
> -Ursprüngliche Nachricht-
> Von: Kumar, Abhishek (IT Information Services ) 
> [mailto:abhishek.kum...@originenergy.com.au] 
> Gesendet: Dienstag, 10. Januar 2017 12:17
> An: users@tomcat.apache.org
> Betreff: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token
> 
> 
> Hi,
> 
> The Apache Tomcat web server running on the Load balancer is affected by an 
> information disclosure vulnerability in the index page of the Manager and 
> Host Manager applications. An unauthenticated attacker can exploit this 
> vulnerability to obtain a valid cross-site request forgery (CSRF) token 
> during the redirect issued when requesting /manager/ or /host-manager/. This 
> token can be utilized by an attacker to construct a CSRF attack.
> 
> This is a Vulnerability issue with Tomcat 8.0.15.
> 
> We have this version of Tomcat installed in our Servers.
> 
> As suggested by Tomcat, this has been addressed and fixed after 8.0.32 
> versions.
> 
> Restrict access to the /manager URL from unauthorised IP addresses by 
> implementing access control lists that only permit authorised management 
> stations or subnets. For more information, see:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_security-2D8.html-23Fixed-5Fin-5FApache-5FTomcat-5F8.0.32=DgIFAg=ZgVRmm3mf2P1-XDAyDsu4A=-JJsXOks_2Pd13691jEHA6PBSyPcGzblOMm00qdlxbs=54nd4qu7eMUZgW9FFIX2Q9G2FdQGJ69mCZu7VvFyN0s=y_OfZJOm3x6d8KgLtJS6flhRUDt_I8Aqk6kymbu3u2k=
> 
> 
> But, We do not want to upgrade the Tomcat right now.
> 
> Is there a way to implement this fix in our current Tomcat Version.
> 
> 
> Kind Regards,
> Abhishek Kumar
> 
> Note: This email, including any attachments, is confidential. If you have 
> received this email in error, please advise the sender and delete it and all 
> copies of it from your system. If you are not the intended recipient of this 
> email, you must not use, print, distribute, copy or disclose its content to 
> anyone
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


from a security standpoint there is no way around updating.

Specifically the CSRF attack is executed from the client, so whoever is at one 
of the authorized management stations will be executing the CSRF requests.

Aside from this one vulnerability all versions up to the current 8.0.40 fix a 
whole load of flaws. So whenever you restrict access to the management console 
(via RemoteAddrValve), all other vulnerabilities that are more than Info 
disclosures will still persist.

Best regards

Peter


Peter Kreuser
AirPlus International 
Security Officer - Application Development

-
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

AW: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token

2017-01-10 Thread Kreuser, Peter

Hi Abishek,
 
> -Ursprüngliche Nachricht-
> Von: Kumar, Abhishek (IT Information Services ) 
> [mailto:abhishek.kum...@originenergy.com.au] 
> Gesendet: Dienstag, 10. Januar 2017 12:17
> An: users@tomcat.apache.org
> Betreff: Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token
> 
> 
> Hi,
> 
> The Apache Tomcat web server running on the Load balancer is affected by an 
> information disclosure vulnerability in the index page of the Manager and 
> Host Manager applications. An unauthenticated attacker can exploit this 
> vulnerability to obtain a valid cross-site request forgery (CSRF) token 
> during the redirect issued when requesting /manager/ or /host-manager/. This 
> token can be utilized by an attacker to construct a CSRF attack.
> 
> This is a Vulnerability issue with Tomcat 8.0.15.
> 
> We have this version of Tomcat installed in our Servers.
> 
> As suggested by Tomcat, this has been addressed and fixed after 8.0.32 
> versions.
> 
> Restrict access to the /manager URL from unauthorised IP addresses by 
> implementing access control lists that only permit authorised management 
> stations or subnets. For more information, see:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_security-2D8.html-23Fixed-5Fin-5FApache-5FTomcat-5F8.0.32=DgIFAg=ZgVRmm3mf2P1-XDAyDsu4A=-JJsXOks_2Pd13691jEHA6PBSyPcGzblOMm00qdlxbs=54nd4qu7eMUZgW9FFIX2Q9G2FdQGJ69mCZu7VvFyN0s=y_OfZJOm3x6d8KgLtJS6flhRUDt_I8Aqk6kymbu3u2k=
> 
> 
> But, We do not want to upgrade the Tomcat right now.
> 
> Is there a way to implement this fix in our current Tomcat Version.
> 
> 
> Kind Regards,
> Abhishek Kumar
> 
> Note: This email, including any attachments, is confidential. If you have 
> received this email in error, please advise the sender and delete it and all 
> copies of it from your system. If you are not the intended recipient of this 
> email, you must not use, print, distribute, copy or disclose its content to 
> anyone
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


from a security standpoint there is no way around updating.

Specifically the CSRF attack is executed from the client, so whoever is at one 
of the authorized management stations will be executing the CSRF requests.

Aside from this one vulnerability all versions up to the current 8.0.40 fix a 
whole load of flaws. So whenever you restrict access to the management console 
(via RemoteAddrValve), all other vulnerabilities that are more than Info 
disclosures will still persist.

Best regards

Peter


Peter Kreuser
AirPlus International 
Security Officer - Application Development

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

Vulnerability Issue with Apache Tomcat 8.0.15 with CSRF token

2017-01-10 Thread Kumar, Abhishek (IT Information Services )

Hi,

The Apache Tomcat web server running on the Load balancer is affected by an
information disclosure vulnerability in the index page of the Manager and Host
Manager applications. An unauthenticated attacker can exploit this
vulnerability to obtain a valid cross-site request forgery (CSRF) token during
the redirect issued when requesting /manager/ or /host-manager/. This token can
be utilized by an attacker to construct a CSRF attack.

This is a Vulnerability issue with Tomcat 8.0.15.

We have this version of Tomcat installed in our Servers.

As suggested by Tomcat, this has been addressed and fixed after 8.0.32 versions.

Restrict access to the /manager URL from unauthorised IP addresses by
implementing access control lists that only permit authorised management
stations or subnets. For more information, see:

https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_security-2D8.html-23Fixed-5Fin-5FApache-5FTomcat-5F8.0.32=DgIFAg=ZgVRmm3mf2P1-XDAyDsu4A=-JJsXOks_2Pd13691jEHA6PBSyPcGzblOMm00qdlxbs=54nd4qu7eMUZgW9FFIX2Q9G2FdQGJ69mCZu7VvFyN0s=y_OfZJOm3x6d8KgLtJS6flhRUDt_I8Aqk6kymbu3u2k=

But, We do not want to upgrade the Tomcat right now.

Is there a way to implement this fix in our current Tomcat Version.

Kind Regards,
Abhishek Kumar

Note: This email, including any attachments, is confidential. If you have
received this email in error, please advise the sender and delete it and all
copies of it from your system. If you are not the intended recipient of this
email, you must not use, print, distribute, copy or disclose its content to
anyone

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

Re: Tomcat 8.0.15 - error using Web Services

2016-02-12 Thread jgebhardt

Hi Marina,

did you manage to solve your problem?
I'm running into the same issue that relative URLs are note resolved while
loading the XSD Definitions in Tomcat 8.0.30.

Below you'll find my stacktrace.

Thanks in advance
Joern



java.lang.IllegalArgumentException: The resource path
[/./../../metadaten/fachlich/fachliche-metadaten.xsd] has been normalized to
[null] which is not valid
at
org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:265)
~[tomcat-embed-core-8.0.30.jar:8.0.30]
at
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:212)
~[tomcat-embed-core-8.0.30.jar:8.0.30]
at
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:206)
~[tomcat-embed-core-8.0.30.jar:8.0.30]
at
org.apache.catalina.core.ApplicationContext.getResource(ApplicationContext.java:554)
~[tomcat-embed-core-8.0.30.jar:8.0.30]
at
org.apache.catalina.core.ApplicationContextFacade.getResource(ApplicationContextFacade.java:199)
~[tomcat-embed-core-8.0.30.jar:8.0.30]
at
org.apache.cxf.transport.servlet.ServletContextResourceResolver.resolve(ServletContextResourceResolver.java:82)
~[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.resource.DefaultResourceManager.findResource(DefaultResourceManager.java:113)
~[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.resource.DefaultResourceManager.resolveResource(DefaultResourceManager.java:58)
~[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.ws.addressing.EndpointReferenceUtils$SchemaLSResourceResolver.resolveResource(EndpointReferenceUtils.java:150)
~[cxf-core-3.1.4.jar:3.1.4]
at
com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1082)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchema(XSDHandler.java:2048)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1004)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1116)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1116)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1116)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:616)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
~[na:1.8.0_66]
at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
~[na:1.8.0_66]
at
org.apache.cxf.ws.addressing.EndpointReferenceUtils.createSchema(EndpointReferenceUtils.java:626)
[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.ws.addressing.EndpointReferenceUtils.getSchema(EndpointReferenceUtils.java:672)
[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.interceptor.AbstractInDatabindingInterceptor.setDataReaderValidation(AbstractInDatabindingInterceptor.java:116)
[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:162)
[cxf-rt-wsdl-3.1.4.jar:3.1.4]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
[cxf-core-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
[cxf-rt-transports-http-3.1.4.jar:3.1.4]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)

Re: Tomcat 8.0.15

2016-01-29 Thread Mark Thomas

On 29/01/2016 18:18, juliesur wrote:
> My webapp does show poor performance and stops responding after a while ,
> with these errors in the log.
> I have been unable to replicate the issue in my testing environment during
> load testing. 
> The error appears only in production .
> 
> I haven't tried another connector or diff tomcat version. I want to confirm
> this as a bug before suggesting the team to upgrade or make changes.

The evidence points to an application bug. You are getting an NPE from
the Context. That suggests the Request has been recycled and something
in the application is retaining a reference to the Request and trying to
use it.

Mark


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

RE: Tomcat 8.0.15

2016-01-29 Thread juliesur

My webapp does show poor performance and stops responding after a while ,
with these errors in the log.
I have been unable to replicate the issue in my testing environment during
load testing. 
The error appears only in production .

I haven't tried another connector or diff tomcat version. I want to confirm
this as a bug before suggesting the team to upgrade or make changes.




--
View this message in context: 
http://tomcat.10.x6.nabble.com/Re-Tomcat-8-0-15-tp5044779p5045814.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: Tomcat 8.0.15

2016-01-07 Thread Caldarale, Charles R

> From: Julie Sur [mailto:julie...@gmail.com] 
> Subject: Re: Tomcat 8.0.15

> I am using tomcat 8.0.15, jdk1.8.0_45 with my application and I am seeing
> below errors in my log. Is this a bug with the tomcat version that I am
> using ?

Could be, but it's more likely an application bug.  Try running with the 
current level (8.0.30).

> TomcatLog Error processing request java.lang.NullPointerException
>  at
> org.apache.catalina.connector.Request.notifyAttributeAssigned(Request.java:1492)

Is your webapp hanging onto a request or response object after the request has 
completed?  Typical errors include storing the reference in a ThreadLocal, 
servlet instance field, or static field.

> TomcatLog Error finishing response java.lang.NullPointerException
>  at
> org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:234)

Have you tried one of the other  types?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat 8.0.15

2016-01-07 Thread Julie Sur

Resending the email as I got failure notification earlier

Thanks
Julie

On Thu, Jan 7, 2016 at 12:44 PM, Julie Sur <julie...@gmail.com> wrote:

> Hi,
> I am using tomcat 8.0.15, jdk1.8.0_45 with my application and I am seeing
> below errors in my log. Is this a bug with the tomcat version that I am
> using ?
>
> TomcatLog Error processing request java.lang.NullPointerException
>  at
> org.apache.catalina.connector.Request.notifyAttributeAssigned(Request.java:1492)
>
>  at
> org.apache.catalina.connector.Request.setAttribute(Request.java:1482)
>  at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
>
>  at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>
>  at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>
>  at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
>  at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085)
>
>  at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
>
>  at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
>
>  at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
>
>  at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
>
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>  at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
>  at java.lang.Thread.run(Thread.java:745)
>
> and
> TomcatLog Error finishing response java.lang.NullPointerException
>  at
> org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:234)
>
>  at
> org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:189)
>
>  at
> org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:177)
>
>  at
> org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:739)
>
>  at org.apache.coyote.Response.action(Response.java:179)
>  at
> org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:369)
>
>  at
> org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1773)
>
>  at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1142)
>
>  at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
>
>  at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
>
>  at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
>
>  at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
>
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>  at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
>  at java.lang.Thread.run(Thread.java:745)
>
> Thank you for looking into this
> Julie Sur
>

Re: PNG images are served intermittently in Apache Tomcat 8.0.15

2015-03-31 Thread Mark Thomas

On 31/03/2015 10:29, Selvakumar Sellamuthu Ayyavu wrote:

 Question:
 
 Is it a known problem?

No.

 If so, can I get a link from issue tracker?

N/A.

 Can I have a work around?

N/A.

 If you want more info, please let me know...

1. Do you see the issue with Apache Tomcat 8.0.21?

2. If yes, please provide the steps to reproduce the issue from a clean
install of Apache Tomcat 8.0.21 downloaded from the ASF.

Mark


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

PNG images are served intermittently in Apache Tomcat 8.0.15

2015-03-31 Thread Selvakumar Sellamuthu Ayyavu

Hi All,

Problem: PNG images are served intermittently from Apache Tomcat 8.0.15 in IE8
Platform: Windows Server 2008

Description:
I have recently migrated from Tomcat 7 to Tomcat 8.
Everything is working fine in Tomcat 8. Except these PNGs.
But when I run WAR in Tomcat 7 these problems are not happening.
This happens only with IE8 +tomcat 8 combination.

I gone thru server logs and app logs and found no clues.
So I was searching for reason and captured network logs . PFA!

What I found peculiar is, whenever IE8 didn't show the PNGs, the amount of
bytes received where 1 byte and it will have 7577 bytes when IE 8 shows image.

CSS code:
#header{background:url(../images/header/header.png) #3C4981 left top
no-repeat;position:relative;width:960px;}

HTML code:

div id=header/

Also post a question in
http://serverfault.com/questions/679514/png-images-are-truncated-and-served-intermittently-from-apache-tomcat-8-0-15

Question:
Is it a known problem? If so, can I get a link from issue tracker?
Can I have a work around?

If you want more info, please let me know..

Thanks and Regards,
Selvakumar.A.S
HCL Technologies,Chennai

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.

entry
pageref0/pageref

startedDateTime2015-03-30T16:08:25.690+00:00/startedDateTime
time93/time
request
methodGET/method

urlhttps://cit2b.usr51/gsportal/resources/images/header/hsbc-beam-react-blue.png/url
httpVersionHTTP/1.1/httpVersion
cookies
cookie
nameJSESSIONID/name

valueD3449B609856469C0AF05DBB111D0A85/value
/cookie
cookie
nameGSActive/name
valuetrue/value
/cookie
/cookies
headers
header
nameAccept/name
valueimage/png,
image/svg+xml, image/*;q=0.8, */*;q=0.5/value
/header
header
nameReferer/name

valuehttps://cit2b.usr51/gsportal/portal/home?execution=e1s2amp;1977430702=16-0-6887994D00888A5AA6369FF487640D5B/value
/header
header
nameAccept-Language/name
valueen-GB/value
/header
header
nameUser-Agent/name
valueMozilla/5.0 (compatible;
MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)/value
/header
header
nameAccept-Encoding/name
valuegzip, deflate/value
/header
header

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-23 Thread Jérémie Barthés


Hi,

I send you the patch from 8.0.15
Tell me if it doesn't match with what you expected
Kind regards,

Jérémie


Index: RewriteValve.java
===
--- RewriteValve.java(revision 1661627)
+++ RewriteValve.java(working copy)
@@ -45,6 +45,11 @@
 import org.apache.catalina.connector.Response;
 import org.apache.catalina.util.LifecycleSupport;
 import org.apache.catalina.valves.ValveBase;
+import org.apache.catalina.valves.rewrite.Resolver;
+import org.apache.catalina.valves.rewrite.ResolverImpl;
+import org.apache.catalina.valves.rewrite.RewriteCond;
+import org.apache.catalina.valves.rewrite.RewriteMap;
+import org.apache.catalina.valves.rewrite.RewriteRule;
 import org.apache.tomcat.util.buf.CharChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
 import org.apache.tomcat.util.net.URL;
@@ -472,11 +477,31 @@
 chunk.append(host.toString());
request.getCoyoteRequest().serverName().toChars();
 }
+
+boolean folderRedirect = false;
+try{
+request.getMappingData().recycle();
+ 
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

+null, request.getMappingData());
+ if(request.getMappingData().redirectPath.toString()!=null){
+folderRedirect = true;
+}
+} catch (Exception e){
+//ignore
+}
+
 request.getMappingData().recycle();
 // Reinvoke the whole request recursively
 try {
request.getConnector().getProtocolHandler().getAdapter().service
 (request.getCoyoteRequest(), 
response.getCoyoteResponse());

+
+if(folderRedirect  
response.getCoyoteResponse().getStatus() == 302){
+ 
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith(/)){
+String requestParam = 
request.getQueryString() == null ?  : '?' + request.getQueryString();
+response.setHeader(Location, 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/' 
+ requestParam);

+}
+}
 } catch (Exception e) {
 // This doesn't actually happen in the 
Catalina adapter implementation

 }



Le 20/02/2015 18:03, Konstantin Kolinko a écrit :

2015-02-20 19:41 GMT+03:00 Christopher Schultz ch...@christopherschultz.net:

Jérémie,

On 2/20/15 4:48 AM, Jérémie Barthés wrote:

instead of just a snippet of fixed code

Sorry Chris,i didn't read this.

How do you want me to provide the patch ?

Presumably, you have a copy of the source code. If you checked-out
from svn, just do this:

/path/to/tomcat-8.0.15 $ svn diff  patch.file

and post the patch file.

If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
a pristine copy of the file and then do:

/path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
java/org/apache/catalina/valves/rewrite/RewriteValve.java \
 patch.file

The above command shall use diff -u to generate Unified Diff format.

Documentation:
http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests

Best regards,
Konstantin Kolinko

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



Index: RewriteValve.java
===
--- RewriteValve.java   (revision 1661627)
+++ RewriteValve.java   (working copy)
@@ -45,6 +45,11 @@
 import org.apache.catalina.connector.Response;
 import org.apache.catalina.util.LifecycleSupport;
 import org.apache.catalina.valves.ValveBase;
+import org.apache.catalina.valves.rewrite.Resolver;
+import org.apache.catalina.valves.rewrite.ResolverImpl;
+import org.apache.catalina.valves.rewrite.RewriteCond;
+import org.apache.catalina.valves.rewrite.RewriteMap;
+import org.apache.catalina.valves.rewrite.RewriteRule;
 import org.apache.tomcat.util.buf.CharChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
 import org.apache.tomcat.util.net.URL;
@@ -472,11 +477,31 @@
 chunk.append(host.toString());
 request.getCoyoteRequest().serverName().toChars();
 }
+
+boolean folderRedirect = false;
+try{
+   request.getMappingData().recycle();
+   
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
 request.getCoyoteRequest().requestURI

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Jérémie Barthés


Le 20/02/2015 11:22, Rémy Maucherat a écrit :

2015-02-20 10:31 GMT+01:00 Jérémie Barthés j.bart...@oodrive.fr:


I send you the patch i did to fix my issue with the RewriteValve (it was
for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic
folder '/' redirection occurs. The RewriteValve will rewrite the redirected
URL.


I think the current behavior is 100% correct, so no patch should be
integrated to fix this IMO. The redirection could be useful to avoid
relative paths issues.

Rémy



Weird way to think code. My function ramdomly redirect or forward is 
100% correct behavior troll. I had to spend many days of work to find why
http://localhost:8080/mypath/async = 
http://localhost:8080/examples/jsp/async/

http://localhost:8080/mypath/async/ = http://localhost:8080/mypath/async/
And always think that users will consider first it fails because they 
didn't did configure well rewrite.config or made mistakes in server.xml 
or any else. Not because there's a 100% correct behavior conflict 
between RewriteValve and coyote's Adapter mapper redirection if some of 
your resources are folders.







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

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Rémy Maucherat

2015-02-20 10:31 GMT+01:00 Jérémie Barthés j.bart...@oodrive.fr:

 I send you the patch i did to fix my issue with the RewriteValve (it was
 for the 8.0.15),
 The goal of that patch is to block the RewriteValve if a 302 automatic
 folder '/' redirection occurs. The RewriteValve will rewrite the redirected
 URL.


I think the current behavior is 100% correct, so no patch should be
integrated to fix this IMO. The redirection could be useful to avoid
relative paths issues.

Rémy

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Felix Schumacher


Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains 
:

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
Valve
className=org.apache.catalina.valves.rewrite.RewriteValve /
in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match 
the

URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the correct URL.
And this is what will be shown in the browser URL bar.  This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache 
this

response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a real response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL 
points

to an existing directory, and if yes add the terminating / yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config


...

will do the trick. I think -d will not work, since /mypath/async is 
not

existant, it only feels like a directory.


Not clear: the implementation for -d is (case 0 below, from file
ResolverImpl.java):

148 @Override
149 public boolean resolveResource(int type, String name) {
150 WebResourceRoot resources = 
request.getContext().getResources();

151 WebResource resource = resources.getResource(name);
152 if (!resource.exists()) {
153 return false;
154 } else {
155 switch (type) {
156 case 0:
157 return (resource.isDirectory());
158 case 1:
159 return (resource.isFile());
160 case 2:
161 return (resource.isFile() 
resource.getContentLength()  0);
162 default:
163 return false;
164 }
165 }
166 }

Since it checks resources and the OP was actually talking about a path
that is a folder in his webapp, -d could work.


Right, but given the examples and instructions from the op, it seems to 
me, that async (source) is not a directory.


I think the op wants to mimic [P] behaviour, which is not implemented 
and wants to point out that
the valve behaves differently when operating on a directory like url and 
one that is not. In the
former it will do an internal forward in the latter an external 
redirect.


As proxy mode is not supported and documented, I tend to say, that it is 
a mildly annoying

inconsitency, but not a bug per se.

Regards
 Felix



Regards,

Rainer

-
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: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Jérémie Barthés

I send you the patch i did to fix my issue with the RewriteValve (it was 
for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic 
folder '/' redirection occurs. The RewriteValve will rewrite the 
redirected URL.


first step :
http://localhost:8080/mypath/async = rewritten to 
http://localhost:8080/examples/jsp/async, 302 redirection occurs, 
rollback and redirect to http://localhost:8080/mypath/async/

second step :
now the server receive http://localhost:8080/mypath/async/ = forward to 
http://localhost:8080/examples/jsp/async/

mission complete

The patch may be a little bit dirty since it the first time i add code 
into tomcat and i don't understand all of this.


It starts at the line 481 of the RewriteValve.java

//boolean to know if the rewritten resource is a 
folder and need a redirection

boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}

request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), 
response.getCoyoteResponse());


if(folderRedirect  
response.getCoyoteResponse().getStatus() == 302){

if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith(/)){
String requestParam = 
request.getQueryString() == null ?  : '?' + request.getQueryString();
response.setHeader(Location, 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/' 
+ requestParam);

}
}
} catch (Exception e) {
// This doesn't actually happen in the Catalina 
adapter implementation

}


Le 20/02/2015 09:34, Felix Schumacher a écrit :

Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that 
contains :

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
Valve
className=org.apache.catalina.valves.rewrite.RewriteValve /
in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the
URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the correct URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache this
response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a real response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL points
to an existing directory, and if yes add the terminating / yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config


...


will do the trick. I think -d will not work, since /mypath/async is not
existant, it only feels like a directory.


Not clear: the implementation for -d is (case

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Jérémie Barthés


instead of just a snippet of fixed code

Sorry Chris,i didn't read this.

How do you want me to provide the patch ?

Jérémie

Le 20/02/2015 10:31, Jérémie Barthés a écrit :
I send you the patch i did to fix my issue with the RewriteValve (it 
was for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic 
folder '/' redirection occurs. The RewriteValve will rewrite the 
redirected URL.


first step :
http://localhost:8080/mypath/async = rewritten to 
http://localhost:8080/examples/jsp/async, 302 redirection occurs, 
rollback and redirect to http://localhost:8080/mypath/async/

second step :
now the server receive http://localhost:8080/mypath/async/ = forward 
to http://localhost:8080/examples/jsp/async/

mission complete

The patch may be a little bit dirty since it the first time i add code 
into tomcat and i don't understand all of this.


It starts at the line 481 of the RewriteValve.java

//boolean to know if the rewritten resource is a 
folder and need a redirection

boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}

request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), 
response.getCoyoteResponse());


if(folderRedirect  
response.getCoyoteResponse().getStatus() == 302){
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith(/)){ 

String requestParam = 
request.getQueryString() == null ?  : '?' + request.getQueryString();
response.setHeader(Location, 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + 
'/' + requestParam);

}
}
} catch (Exception e) {
// This doesn't actually happen in the 
Catalina adapter implementation

}


Le 20/02/2015 09:34, Felix Schumacher a écrit :

Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that 
contains :

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
Valve
className=org.apache.catalina.valves.rewrite.RewriteValve /
in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match 
the

URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the correct URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache 
this

response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a real response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL 
points

to an existing directory, and if yes add the terminating / yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/20/15 4:48 AM, Jérémie Barthés wrote:
 instead of just a snippet of fixed code
 
 Sorry Chris,i didn't read this.
 
 How do you want me to provide the patch ?

Presumably, you have a copy of the source code. If you checked-out
from svn, just do this:

/path/to/tomcat-8.0.15 $ svn diff  patch.file

and post the patch file.

If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
a pristine copy of the file and then do:

/path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
   java/org/apache/catalina/valves/rewrite/RewriteValve.java \
patch.file

- -chris

 Le 20/02/2015 10:31, Jérémie Barthés a écrit :
 I send you the patch i did to fix my issue with the RewriteValve
 (it was for the 8.0.15), The goal of that patch is to block the
 RewriteValve if a 302 automatic folder '/' redirection occurs.
 The RewriteValve will rewrite the redirected URL.
 
 first step : http://localhost:8080/mypath/async = rewritten to 
 http://localhost:8080/examples/jsp/async, 302 redirection
 occurs, rollback and redirect to
 http://localhost:8080/mypath/async/ second step : now the server
 receive http://localhost:8080/mypath/async/ = forward to
 http://localhost:8080/examples/jsp/async/ mission complete
 
 The patch may be a little bit dirty since it the first time i add
 code into tomcat and i don't understand all of this.
 
 It starts at the line 481 of the RewriteValve.java
 
 //boolean to know if the rewritten resource is a folder and need
 a redirection boolean folderRedirect = false; try{ 
 request.getMappingData().recycle(); 
 request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),

 
request.getCoyoteRequest().requestURI(),
 null, request.getMappingData()); 
 if(request.getMappingData().redirectPath.toString()!=null){ 
 folderRedirect = true; } } catch (Exception e){ //ignore }
 
 request.getMappingData().recycle(); // Reinvoke the whole request
 recursively try { 
 request.getConnector().getProtocolHandler().getAdapter().service 
 (request.getCoyoteRequest(), response.getCoyoteResponse());
 
 if(folderRedirect  response.getCoyoteResponse().getStatus() ==
 302){ 
 if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith(/)){


 
String requestParam =
 request.getQueryString() == null ?  : '?' +
 request.getQueryString(); response.setHeader(Location, 
 request.getCoyoteRequest().requestURI().getByteChunk().toString()
 + '/' + requestParam); } } } catch (Exception e) { // This
 doesn't actually happen in the Catalina adapter implementation }
 
 
 Le 20/02/2015 09:34, Felix Schumacher a écrit :
 Am 20.02.2015 08:49, schrieb Rainer Jung:
 Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
 Am 19.02.2015 um 21:41 schrieb André Warnier:
 Jérémie Barthés wrote: ...
 
 
 Make a file rewrite.config in conf/Catalina/localhost/
 that contains : RewriteRule^/mypath/(.*)$
 /examples/jsp/$1
 
 copy the line Valve 
 className=org.apache.catalina.valves.rewrite.RewriteValve
 / in the conf/server.xml file, line 131
 
 
 Since this is a Valve, it will run before Tomcat attempts
 to match the URL to an actual directory or webapp.
 
 
 try the followings URLs :
 
 
 1) http://localhost:8080/mypath/async
 
 This matches the rewrite rule, so it will be rewritten to
 URL
 
 /examples/jsp/async
 
 Then Tomcat will attempt to match this to a directory or
 webapp, and find that
 (catalina_base)/webapps/examples/jsp/async is a
 directory. It will thus respond to the browser with a 302
 re-direct to
 
 http://localhost:8080/examples/jsp/async/
 
 which is actually the correct URL. And this is what
 will be shown in the browser URL bar. This, in my view,
 is expected behaviour.  The server does that, so that
 when an actual response is generated (for the correct
 URL http://localhost:8080/examples/jsp/async/), the
 browser can cache this response under the correct URL.
 
 Then the browser re-issues a request for
 
 http://localhost:8080/examples/jsp/async/
 
 and that is when Tomcat will actually generate a real
 response, because this time it is a correct URL. So the
 response appears to the browser, as coming from
 
 http://localhost:8080/examples/jsp/async/
 
 which is correct.
 
 2) http://localhost:8080/mypath/async/
 
 This also matches the rewrite rule, so it gets rewritten
 to
 
 http://localhost:8080/examples/jsp/async/
 
 which is a correct URL. Thus Tomcat will immediately
 generate a real response (without an intermediate 302
 redirect), which will be appear in the browser URL bar as
 a response to
 
 http://localhost:8080/mypath/async/
 
 This is also expected behaviour.
 
 I believe that if you do not want to see the first
 redirect URL
 
 http://localhost:8080/examples/jsp/async/
 
 in the browser, you have to modify your rewrite rules,
 perhaps by using a RewriteCond with the -d flag, to check
 first if the URL points to an existing directory, and if
 yes add

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-20 Thread Konstantin Kolinko

2015-02-20 19:41 GMT+03:00 Christopher Schultz ch...@christopherschultz.net:

 Jérémie,

 On 2/20/15 4:48 AM, Jérémie Barthés wrote:
 instead of just a snippet of fixed code

 Sorry Chris,i didn't read this.

 How do you want me to provide the patch ?

 Presumably, you have a copy of the source code. If you checked-out
 from svn, just do this:

 /path/to/tomcat-8.0.15 $ svn diff  patch.file

 and post the patch file.

 If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
 a pristine copy of the file and then do:

 /path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
java/org/apache/catalina/valves/rewrite/RewriteValve.java \
 patch.file

The above command shall use diff -u to generate Unified Diff format.

Documentation:
http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests

Best regards,
Konstantin Kolinko

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

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

2015-02-19 Thread André Warnier

Jérémie Barthés wrote:
...

Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
Valve
className=org.apache.catalina.valves.rewrite.RewriteValve /

in the conf/server.xml file, line 131

Since this is a Valve, it will run before Tomcat attempts to match the URL to an actual
directory or webapp.

try the followings URLs :

1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

/examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and find that
(catalina_base)/webapps/examples/jsp/async is a directory.

It will thus respond to the browser with a 302 re-direct to