Re: Tomcat APR protocol SSL certificate information.

[Mark Thomas]

On 16/12/2015 13:26, Nithesh Kb wrote:
> [image: Inline image 1]
> 
> 
> Got this mail! ,
> Does it means can we use keystore for APR protocol using this new TC-native
> ??

It needs changes on the Tomcat side as well. Those are currently only
available in the 9.0.x source tree. They will be included in the next
9.0.x release.

Mark


> 
> 
> 
> Thanks,
> Nithesh
> 
>>
>>
> On Wed, Dec 16, 2015 at 1:09 PM, Garcia Aparici, Carlos 
> wrote:
> 
>> In many of our tomcats we use the pfx directly on the conector. Its
>> similar to a keystore
>>
>>
>> Enviado de Samsung Mobile
>>
>>
>>
>>  Mensaje original 
>> De: Nithesh Kb 
>> Fecha: 15/12/2015 16:21 (GMT+01:00)
>> Para: Tomcat Users List 
>> Asunto: Re: Tomcat APR protocol SSL certificate information.
>>
>>
>> *Thanks David,Thomas.*
>> If my understanding is not wrong.
>> Till tomcat version 8, we need to provide cert and key separately for
>> openssl ssl APR, like
>>
>> *(SSLCertificateFile="/aa/server.crt"SSLCertificateKeyFile="/aa/server.key")*
>> But tomcat 9 we can use keystore to store cert and key and configure it to
>> connector like  *keystoreFile="/aa/tomcat.**keystore"*
>>
>> *Thanks,*
>> *Nithesh*
>>
>> On Tue, Dec 15, 2015 at 8:40 PM, Mark Thomas  wrote:
>>
>>> On 15/12/2015 15:07, David Newman wrote:
 When you use APR the SSL implementation is coming from openssl instead
>> of
 java.  openssl has no use for java keystore files.  So it becomes more
>>> like
 an apache httpd config with separate files for keys and certificates.
>>>
>>> True, but as of Tomcat 9 (and will hopefully be back-ported to an 8.1.x
>>> at some point) you can use Java keystores with OpenSSL.
>>>
>>> Mark
>>>

 On Tue, Dec 15, 2015 at 5:12 AM, Nithesh Kb 
>>> wrote:

> HI,
> I have build APR libraries Openssl and tc-native also i have created
> openssl libraries. both HTTP and HTTPS is working fine.
>
> *openssl genrsa -des3 -out server.key 2048 *
> *openssl req -new -key server.key -out server.csr*
> *cp server.key server.key.org *
> *openssl rsa -in server.key.org  -out
>>> server.key*
> *openssl x509 -req -days 365 -in server.csr -signkey server.key -out
> server.crt*
>
> i get server.crt and server.key.
>
> I added this entry,in connector
>
>
> *protocol="org.apache.coyote.http11.Http11AprProtocol"*
> *SSLCertificateFile="/aa/server.crt"*
> *SSLCertificateKeyFile="/aa/server.key"*
>
> *If i do this much, it will work!!*
>
> *But the question is, is it possible to put these two certificate in
> keystore and can we add only that keystore in our connector ?*
> *something like, keystoreFile="/aa/tomcat.keystore"*
>
> *i tried this but didn't worked,*
>
> *
>
>>>
>> http://stackoverflow.com/questions/17695297/importing-the-private-key-public-certificate-pair-in-the-java-keystore
> <
>
>>>
>> http://stackoverflow.com/questions/17695297/importing-the-private-key-public-certificate-pair-in-the-java-keystore
>> *
>
> *please help me to understand these certificate stuffs. *
>
>
>
> *Thanks,*
> *Nithesh*
>

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>> 
>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>> contiene información de carácter confidencial exclusivamente dirigida a su
>> destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
>> notificado que la lectura, utilización, divulgación y/o copia sin
>> autorización está prohibida en virtud de la legislación vigente. En el caso
>> de haber recibido este correo electrónico por error, se ruega notificar
>> inmediatamente esta circunstancia mediante reenvío a la dirección
>> electrónica del remitente.
>> Evite imprimir este mensaje si no es estrictamente necesario.
>>
>> This email and any file attached to it (when applicable) contain(s)
>> confidential information that is exclusively addressed to its recipient(s).
>> If you are not the indicated recipient, you are informed that reading,
>> using, disseminating and/or copying it without authorisation is forbidden
>> in accordance with the legislation in effect. If you have received this
>> email by mistake, please immediately notify the sender of the situation by
>> resending it to their email address.
>> Avoid printing this message if it is not absolutely necessary.
>>
> 


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

Re: Generated Dump file for HeapDumpOnOutOfMemoryError

[Christopher Schultz]

Yogesh,

On 12/16/15 3:50 AM, Yogesh Patel wrote:
> Working directory for tomcat is like "D:\tools\tomcat7-4", but there is no
> file generated under this directory.

Maybe a file permissions error? Can the user running your service write
to D:\tools\tomcat7-4? If you are in fact running as a service, the
local service user has virtually no privileges (which is appropriate).

-chris

> On 15 December 2015 at 06:48, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
>> Yogesh,
>>
>> On 12/14/15 1:34 AM, Yogesh Patel wrote:
>>> We set -XX:+HeapDumpOnOutOfMemoryError
>>> but we couldn't find any file which contains the heap dump.
>>> As per the docs file name will be "./java_pid.hprof" but there is no
>>> such file generated on OutOFMemoryError.
>>
>> What is the CWD of the Tomcat process? You can find is on Linux by
>> poking-around in the /proc/[pid] fs... can probably get it with some
>> work using lsof, etc.
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 
> 

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

Re: Tomcat 7.0.62 fill logs directories from a bad GET request.

[Mark Thomas]

On 14/12/2015 17:47, Wyatt Zacharias wrote:
> So I've been having this one intermittent issue with a tomcat app, where it
> will occasionally go crazy
> and spit out gigabytes of logs until the directory fills up. I spent some
> time tracing through and replaying all of the GET requests that were
> received around the time that it happened, and I've found that any GET
> request where the URI begins with a period will cause the issue.
> 
> Has anyone else experienced this? I'm running Apache Tomcat 7.0.62 with
> Java 1.8.0_60 on RedHat 6.7.

I haven't seen this reported previously and I can't repeat it based on
your description. You'll need to provide the exact steps to reproduce
this on a clean install of the latest 7.0.x release (7.0.67 as I type
this) or the latest release of any of the currently supported Tomcat
major versions.

Mark


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

Re: Tomcat APR protocol SSL certificate information.

[Nithesh Kb]

[image: Inline image 1]


Got this mail! ,
Does it means can we use keystore for APR protocol using this new TC-native
??



Thanks,
Nithesh

>
>
On Wed, Dec 16, 2015 at 1:09 PM, Garcia Aparici, Carlos 
wrote:

> In many of our tomcats we use the pfx directly on the conector. Its
> similar to a keystore
>
>
> Enviado de Samsung Mobile
>
>
>
>  Mensaje original 
> De: Nithesh Kb 
> Fecha: 15/12/2015 16:21 (GMT+01:00)
> Para: Tomcat Users List 
> Asunto: Re: Tomcat APR protocol SSL certificate information.
>
>
> *Thanks David,Thomas.*
> If my understanding is not wrong.
> Till tomcat version 8, we need to provide cert and key separately for
> openssl ssl APR, like
>
> *(SSLCertificateFile="/aa/server.crt"SSLCertificateKeyFile="/aa/server.key")*
> But tomcat 9 we can use keystore to store cert and key and configure it to
> connector like  *keystoreFile="/aa/tomcat.**keystore"*
>
> *Thanks,*
> *Nithesh*
>
> On Tue, Dec 15, 2015 at 8:40 PM, Mark Thomas  wrote:
>
> > On 15/12/2015 15:07, David Newman wrote:
> > > When you use APR the SSL implementation is coming from openssl instead
> of
> > > java.  openssl has no use for java keystore files.  So it becomes more
> > like
> > > an apache httpd config with separate files for keys and certificates.
> >
> > True, but as of Tomcat 9 (and will hopefully be back-ported to an 8.1.x
> > at some point) you can use Java keystores with OpenSSL.
> >
> > Mark
> >
> > >
> > > On Tue, Dec 15, 2015 at 5:12 AM, Nithesh Kb 
> > wrote:
> > >
> > >> HI,
> > >> I have build APR libraries Openssl and tc-native also i have created
> > >> openssl libraries. both HTTP and HTTPS is working fine.
> > >>
> > >> *openssl genrsa -des3 -out server.key 2048 *
> > >> *openssl req -new -key server.key -out server.csr*
> > >> *cp server.key server.key.org *
> > >> *openssl rsa -in server.key.org  -out
> > server.key*
> > >> *openssl x509 -req -days 365 -in server.csr -signkey server.key -out
> > >> server.crt*
> > >>
> > >> i get server.crt and server.key.
> > >>
> > >> I added this entry,in connector
> > >>
> > >>
> > >> *protocol="org.apache.coyote.http11.Http11AprProtocol"*
> > >> *SSLCertificateFile="/aa/server.crt"*
> > >> *SSLCertificateKeyFile="/aa/server.key"*
> > >>
> > >> *If i do this much, it will work!!*
> > >>
> > >> *But the question is, is it possible to put these two certificate in
> > >> keystore and can we add only that keystore in our connector ?*
> > >> *something like, keystoreFile="/aa/tomcat.keystore"*
> > >>
> > >> *i tried this but didn't worked,*
> > >>
> > >> *
> > >>
> >
> http://stackoverflow.com/questions/17695297/importing-the-private-key-public-certificate-pair-in-the-java-keystore
> > >> <
> > >>
> >
> http://stackoverflow.com/questions/17695297/importing-the-private-key-public-certificate-pair-in-the-java-keystore
> > >>> *
> > >>
> > >> *please help me to understand these certificate stuffs. *
> > >>
> > >>
> > >>
> > >> *Thanks,*
> > >> *Nithesh*
> > >>
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> 
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
> notificado que la lectura, utilización, divulgación y/o copia sin
> autorización está prohibida en virtud de la legislación vigente. En el caso
> de haber recibido este correo electrónico por error, se ruega notificar
> inmediatamente esta circunstancia mediante reenvío a la dirección
> electrónica del remitente.
> Evite imprimir este mensaje si no es estrictamente necesario.
>
> This email and any file attached to it (when applicable) contain(s)
> confidential information that is exclusively addressed to its recipient(s).
> If you are not the indicated recipient, you are informed that reading,
> using, disseminating and/or copying it without authorisation is forbidden
> in accordance with the legislation in effect. If you have received this
> email by mistake, please immediately notify the sender of the situation by
> resending it to their email address.
> Avoid printing this message if it is not absolutely necessary.
>

Re: [ANN] Apache Tomcat Native 1.2.3 released

[Nithesh Kb]

Got this mail! ,
Does it means can we use keystore for APR protocol using this new TC-native
??



Thanks,
Nithesh

On Wed, Dec 16, 2015 at 4:52 PM, Mark Thomas  wrote:

> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat Native 1.2.3 stable.
>
> The key features of this release are:
> - Java keystore support.
> - Various fixes to align the Java and native APIs
> - Various fixes if building without OpenSSL
> - Windows binaries built with OpenSSL 1.0.2e
>
> Note that, unless a regression is discovered in 1.2.x, users should now
> be using 1.2.x in preference to 1.1.x.
>
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/native-doc/miscellaneous/changelog.html
>
> Downloads:
> http://tomcat.apache.org/download-native.cgi
>
> The Apache Tomcat Native Library provides portable API for features
> not found in contemporary JDK's. It uses Apache Portable Runtime as
> operating system abstraction layer and OpenSSL for SSL networking and
> allows optimal performance in production environments.
>
>
> Thank you,
> --
> The Apache Tomcat Team
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

[ANN] Apache Tomcat Native 1.1.34 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.1.34 stable.

The key features of this release are:
- Unconditionally disable export Ciphers
- Improve ephemeral key handling for DH and ECDH
- Various fixes to build with newer OPenSSL versions
- Link Windows binaries with OpenSSL 1.0.1q and APR 1.5.1

Note that, unless a regression is discovered in 1.2.x, users should now
be using 1.2.x in preference to 1.1.x.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library provides portable API for features
not found in contemporary JDK's. It uses Apache Portable Runtime as
operating system abstraction layer and OpenSSL for SSL networking and
allows optimal performance in production environments.


Thank you,
-- 
The Apache Tomcat Team

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

Re: Custom Connector class

[Christopher Schultz]

Roel,

On 12/16/15 4:56 AM, Roel Storms wrote:
> It should, if you implement parseParameter and all these other methods
> before getStream is called, in the wrapper itself. But since you haven't
> implemented HttpServletRequest.getParameter* in you example Filter, you
> will end up using Request.getParameter* which will not use
> the HttpServletRequest.getStream since it has no knowledge of this wrapper.
> The wrapped object never uses the wrapped implementation of methods since
> it has no knowledge of the wrapping.

I'm sorry I wasn't clear, but I was suggesting that you use my Filter as
inspiration for writing a Valve. The Valve wouldn't wrap
HttpServletRequest. Instead, it would wrap Tomcat's coyote Request
class, which *is* used to fetch the input stream (or reader).

-chris

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

Determining parallely deployed versions of a webapp programmatically

[l.pe...@senat.fr]

Hi.

I have in some of my apps cron-like tasks, scheduled by libs such as quartz.

As I am also an happy user of the parallel deployment feature of tomcat, 
I was wondering whether, without special privileges such as those of the 
"admin" webapps, I could programatically determine if a webapp is the 
"top" version of a family of webapps.


So, if webapp versions :
* 1.2.1
* 1.2.2
* 1.2.3

are deployed, I should be capable to determine that 1.2.3 is the latest 
and only run the scheduled task in this last one.


Is there any API to achieve that ?

Thanks in advance,

Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


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

Re: Custom Connector class

[Konstantin Kolinko]

2015-12-09 16:35 GMT+03:00 André Warnier (tomcat) :
> On 09.12.2015 14:03, Roel Storms wrote:
>>
>> The real requirement is being able to process the body of a request in a
>> Valve without restricting the servlet to call request.getInputStream,
>> getReader and getStream. I have tried by wrapping the request but some
>> behavior can't be masked. It is also much more simple to implement by just
>> extending the Request class and using this in Connector.createRequest().
>>
>> So the actual requirement is a Valve wanting to process the body but still
>> allowing the target application to call whatever processing method they
>> chose. When the Valve would chose to process the body by calling
>> Request.getInputStream(). The servlet wouldn't be able to call getReader
>> or
>> getParam anymore. I would like my Valve to be transparent in that sense.
>
>
> I am no java nor Tomcat guru, so take this with caution :
> Looking at
>
> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Common_Attributes
> --> maxSavePostSize
>
> makes me think that there is a case where tomcat saves an incoming request
> body, and restores it afterward (after the authentication).  Since the
> authentication takes place before the webapp is called, it cannot know the
> way in which the webapp is going to consume the request body. So the saved
> body must be saved in such a way, that the webapp can afterward consume it
> in the way it chooses.
> Doesn't that provide some clue on how to solve your problem ?

+1. Good idea.

To Roel:
1. See restoreRequest() method in
org.apache.catalina.authenticator.FormAuthenticator
 on how to restore a body of a request after reading it in a Valve.

The method does a lot more (as it has to reset the whole request).
Your task is a bit easier.

2. Top posting is bad.
http://tomcat.apache.org/lists.html#tomcat-users
-> point "6."

Best regards,
Konstantin Kolinko

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

RE: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting

[Cris Berneburg - US]

Mark (and Chris),

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Sent: Wednesday, December 09, 2015 12:08 PM
> To: Tomcat Users List
> Subject: Re: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting
> 
> Mark,
> 
> On 12/9/15 8:46 AM, Mark Thomas wrote:
> > On 09/12/2015 13:39, Cris Berneburg - US wrote:
> >> Aww phooey, I missed it!  I set my reminder incorrectly and ended up 
> >> trying to sign in 20 minutes late.  By the time I did sign in, the place 
> >> was empty.  "Hello, anybody there?"
> > 
> > All is not lost:
> > 
> > https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g
> 
> New and improved... with SOUND!

Thanks for doing the presentation, recording it, AND improving the sound.  :-)

> Your tax dollars at work. ;)
> 
> (Thanks Mark)
> 
> -chris


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

[ANN] Apache Tomcat Native 1.2.3 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.2.3 stable.

The key features of this release are:
- Java keystore support.
- Various fixes to align the Java and native APIs
- Various fixes if building without OpenSSL
- Windows binaries built with OpenSSL 1.0.2e

Note that, unless a regression is discovered in 1.2.x, users should now
be using 1.2.x in preference to 1.1.x.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library provides portable API for features
not found in contemporary JDK's. It uses Apache Portable Runtime as
operating system abstraction layer and OpenSSL for SSL networking and
allows optimal performance in production environments.


Thank you,
-- 
The Apache Tomcat Team

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

Re: Custom Connector class

[Roel Storms]

2015-12-16 14:11 GMT+01:00 Christopher Schultz :

> Roel,
>
> On 12/16/15 4:56 AM, Roel Storms wrote:
> > It should, if you implement parseParameter and all these other methods
> > before getStream is called, in the wrapper itself. But since you haven't
> > implemented HttpServletRequest.getParameter* in you example Filter, you
> > will end up using Request.getParameter* which will not use
> > the HttpServletRequest.getStream since it has no knowledge of this
> wrapper.
> > The wrapped object never uses the wrapped implementation of methods since
> > it has no knowledge of the wrapping.
>
> I'm sorry I wasn't clear, but I was suggesting that you use my Filter as
> inspiration for writing a Valve. The Valve wouldn't wrap
> HttpServletRequest. Instead, it would wrap Tomcat's coyote Request
> class, which *is* used to fetch the input stream (or reader).
>
> -chris
>
> Ok, first of all, sorry for the Top posting, it's a nasty habit that comes
with using the Gmail webclient.

Secondly, If it would wrap the Request without intercepting getParameter()
then a call to HttpServletRequest.getParameter would delegate to the
wrapped Request which in my case, would be a wrapped version of the
original Request. But since I am not intercepting getParameter, it will
result in Request.getParameter being called which leads me back to the
previous e-mail. As long as I am not implementing all the methods that
eventually call getStream,  getInputStream and getReader, I won't get the
desired behavior.

I agree that your filter could be an inspiration for a Valve but it would
have to cover all the methods mentioned in the previous e-mail and it
wouldn't suffice to . I have several sequence diagrams explaining what I
mean.
https://www.dropbox.com/s/ebjs6ixpyqs742n/getParameter.jpg?dl=0
https://www.dropbox.com/s/c9sj00nwqcs9l7y/getParameter2.jpg?dl=0

The first diagram describes what happens if you intercept getReader,
getInputStream and getStream but don't intercept getParameter. The second
diagram shows the interaction as it's supposed to happen but requires the
wrapper implementing all these methods without delegating them to the
wrapped Request.

The other alternative is extending Request with an implementation of
getStream without implementations for getParameter, parseParameters or
readPostBody. This would result in the following (if I use dynamic binding
correctly): https://www.dropbox.com/s/0a3k9qqzonicjvf/getParameter3.jpg?dl=0

I will also look into what Konstantin suggested.



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

Re: Generated Dump file for HeapDumpOnOutOfMemoryError

[Yogesh Patel]

Hi Christopher,

Working directory for tomcat is like "D:\tools\tomcat7-4", but there is no
file generated under this directory.

On 15 December 2015 at 06:48, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Yogesh,
>
> On 12/14/15 1:34 AM, Yogesh Patel wrote:
> > We set -XX:+HeapDumpOnOutOfMemoryError
> > but we couldn't find any file which contains the heap dump.
> > As per the docs file name will be "./java_pid.hprof" but there is no
> > such file generated on OutOFMemoryError.
>
> What is the CWD of the Tomcat process? You can find is on Linux by
> poking-around in the /proc/[pid] fs... can probably get it with some
> work using lsof, etc.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*Thanks & Regards,*

* Yogesh Patel*

Re: CSRF errors after upgrade of tomcat 8

[Mark Thomas]

On 16/12/2015 02:41, Baron Fujimoto wrote:
> On Tue, Dec 15, 2015 at 09:37:45AM +0200, Violeta Georgieva wrote:



>> mapperContextRootRedirectEnabled and
>> mapperDirectoryRedirectEnabled
>>
>> are attributes of the Context so your context.xml should look like the one
>> below:
>>
>> > mapperDirectoryRedirectEnabled="true">
>>WEB-INF/web.xml
>>${catalina.base}/conf/web.xml
>> 
>>
>> Regards,
>> Violeta
> 
> That works! Mahalo for correcting the context.xml syntax. This workaround
> will allow us to stay current with the latest Tomcat release. Is this
> expected to be the default behavior going forward?

Yes. This is the default behaviour for all Tomcat releases going forwards.

Mark


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

Re: Custom Connector class

[Roel Storms]

It should, if you implement parseParameter and all these other methods
before getStream is called, in the wrapper itself. But since you haven't
implemented HttpServletRequest.getParameter* in you example Filter, you
will end up using Request.getParameter* which will not use
the HttpServletRequest.getStream since it has no knowledge of this wrapper.
The wrapped object never uses the wrapped implementation of methods since
it has no knowledge of the wrapping.

2015-12-16 4:06 GMT+01:00 Christopher Schultz 
:

> Roel,
>
> On 12/15/15 5:13 PM, Roel Storms wrote:
> > I don't believe that your suggestion works, but correct me if I'm wrong.
> > You aren't overwriting the getInputStream or getReader method. You are
> > wrapping them, which is a big difference. Since the internal
> > Request#parseParameter() won't use your wrapped version of the method but
> > rather uses it's own version which won't work since you've already called
> > getInputStream or getReader.
>
> My code is a Filter which executes too late. If you implement this as a
> Valve, you ought to be able to capture the input data (whether it is a
> stream or a reader) and re-play it to any code later in the valve
> pipeline. I must admit I haven't read all the Connector/Request code so
> I don't know for sure if a Valve wrapping the (non-spec-defined) request
> object will be sufficient.
>
> > In your case it works since you aren't calling getParameter(). You're
> > implementation works as long as you restrict your application to using
> > getReader or getInputStream. Again, correct me if I'm wrong. Calling
> > HttpRequestRecorderWrapper.getParameter() in the web application, should
> > mess up your wrapper since it doesn't intercepts this method call and
> will
> > invoke the Request.getParameter() which will call Request.getStream() and
> > not HttpRequestRecorderWrapper.getStream() as you're implementation
> > requires.
>
> Servlet code calling HttpServletRequest.getParameter* should end up
> calling getInputStream on the wrapper. If that's not what Tomcat does,
> I'd consider it a bug because Filters are supposed to be able to replace
> request entities and things like that.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>