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

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: 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: 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
>
>

Re: Custom Connector class

[Roel Storms]

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.

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.

Overwriting the getStream, getInputStream and getReader methods would
indeed solve the problem, but the problem is that you aren't overwriting
the method. By the way, I believe that parseParameter uses getStream. But
again, a wrapper does not overwrite the Request.getInputStream or
getReader. I made this same mistake when trying a similar solution to yours.

So in order for getParameter to work in a wrapper, you need to wrap
parseParameter and implement all the other methods that depend on
getStream, getInputStream or getReader, in the wrapper itself. I did the
research and I would have to rewrite more then you suggest (getReader(),
getStream(), getInputStream(), parseParameter(), readPostBody(),
readChunkedPostBody, getParameterMap, getParameterNames,
getParameterValues)  and maybe it's not even possible since some fields
that are used by these implementations are protected and have been set
before the Valve is encountered. These fields don't always have getters and
you might not be able to reproduce the behavior of getParameter (or any
other method) in a wrapper due to this fact. This last part is just an
assumption. I haven't validated that this last issue, indeed renders an
implementation in a wrapper impossible, but it makes it fairly difficult
and error prone. By the way, this is not my only reason for diving into
Tomcat. I need modification to the Manager as well and since it is just a
proof of concept, I am not worried about maintaining this code, which would
indeed be almost impossible.

Thanks for the advice on the size of requests. I'm still pondering on that
issue.

Roel


2015-12-15 2:10 GMT+01:00 Christopher Schultz 
:

> Roel,
>
> On 12/12/15 11:17 AM, Roel Storms wrote:
> > I believe that this is not entirely what I need. As far as I understand
> the
> > code it will detect if getInputStream or getReader has been called by the
> > servlet application. Depending on the usingReader boolean that was set
> as a
> > result, it will either use _inputReaderBuffer or _inputStreamBuffer to
> > fetch the body.
> >
> > In my case I need to retrieve the body in advance and still allow the web
> > application to call either method, getInputStream, getReader,
> getParameter.
> > If I choose to call getInputStream in my Valve to retrieve the body then
> > the web application will be restricted to using getInputStream. If I
> choose
> > getReader then the web application will be restricted to using getReader.
> > If a web application would use ServletRequest.getParameter the
> > documentation says the following:
> >
> > "If the parameter data was sent in the request body, such as occurs with
> an
> > HTTP POST request, then reading the body directly via getInputStream()
> > <
> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
> >
> >  or getReader()
> > <
> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getReader()
> >
> > can
> > interfere with the execution of this method."
> >
> > According to my understanding of the original Tomcat request code,
> > Request.getParam depends on Request.parseParameters which in turn uses
> > Request.readPostBody that uses Request.getStream to obtain the data.
> > getStream also fetches the inputStream of a request so I believe it won't
> > work in combination with a call to getReader.
> >
> > Since your wrapper is not overwriting any method like getParam
> > (getParameterNames, getParameterValues, getParameterMap) I believe these
> > methods will still behave incorrectly when called by the target
> application.
> >
> > I could indeed build a wrapper that would overwrite getStream, getReader,
> > getInputStream, getParam, getParameterNames, etc. But then I would be
> > generating a lot of duplicate code. Since my implementation is purely
> > experimental I don't think it's such big of a problem to modify Tomcat
> > internals (the Connector class).
>
> Honestly, it will be easier to implement this as a Valve. I have posted
> all the code you need for what you want... you 

Re: Custom Connector class

[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

Re: Custom Connector class

[Christopher Schultz]

Roel,

On 12/12/15 11:17 AM, Roel Storms wrote:
> I believe that this is not entirely what I need. As far as I understand the
> code it will detect if getInputStream or getReader has been called by the
> servlet application. Depending on the usingReader boolean that was set as a
> result, it will either use _inputReaderBuffer or _inputStreamBuffer to
> fetch the body.
> 
> In my case I need to retrieve the body in advance and still allow the web
> application to call either method, getInputStream, getReader, getParameter.
> If I choose to call getInputStream in my Valve to retrieve the body then
> the web application will be restricted to using getInputStream. If I choose
> getReader then the web application will be restricted to using getReader.
> If a web application would use ServletRequest.getParameter the
> documentation says the following:
> 
> "If the parameter data was sent in the request body, such as occurs with an
> HTTP POST request, then reading the body directly via getInputStream()
> 
>  or getReader()
> 
> can
> interfere with the execution of this method."
> 
> According to my understanding of the original Tomcat request code,
> Request.getParam depends on Request.parseParameters which in turn uses
> Request.readPostBody that uses Request.getStream to obtain the data.
> getStream also fetches the inputStream of a request so I believe it won't
> work in combination with a call to getReader.
> 
> Since your wrapper is not overwriting any method like getParam
> (getParameterNames, getParameterValues, getParameterMap) I believe these
> methods will still behave incorrectly when called by the target application.
> 
> I could indeed build a wrapper that would overwrite getStream, getReader,
> getInputStream, getParam, getParameterNames, etc. But then I would be
> generating a lot of duplicate code. Since my implementation is purely
> experimental I don't think it's such big of a problem to modify Tomcat
> internals (the Connector class).

Honestly, it will be easier to implement this as a Valve. I have posted
all the code you need for what you want... you might need to move some
of it around a bit in order to get the behavior you want. Note that
getParameter* calls getInputStream/getReader to get the data, so if you
override the stream methods, you'll be able to support everything.

Whatever you do, remember to put a limit on the amount of data you'll
cache in memory, or you risk introducing a very trivial and nasty DOS
vulnerability.

-chris

> 2015-12-09 18:06 GMT+01:00 Christopher Schultz > :
> 
>> Roel,
>>
>> On 12/9/15 8:03 AM, 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.
>>
>> What you want to do can be done with a Valve as long as you don't mind a
>> bit of typing.
>>
>> See this thread where I built pretty much exactly what you're requesting:
>> http://tomcat.markmail.org/thread/fumpfuspt7a3nesz
>>
>> I implemented mine as a Filter, not as a Valve.
>>
>> There's no need to go writing your own Request implementation.
>>
>> -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: Custom Connector class

[Roel Storms]

Chris,

I believe that this is not entirely what I need. As far as I understand the
code it will detect if getInputStream or getReader has been called by the
servlet application. Depending on the usingReader boolean that was set as a
result, it will either use _inputReaderBuffer or _inputStreamBuffer to
fetch the body.

In my case I need to retrieve the body in advance and still allow the web
application to call either method, getInputStream, getReader, getParameter.
If I choose to call getInputStream in my Valve to retrieve the body then
the web application will be restricted to using getInputStream. If I choose
getReader then the web application will be restricted to using getReader.
If a web application would use ServletRequest.getParameter the
documentation says the following:

"If the parameter data was sent in the request body, such as occurs with an
HTTP POST request, then reading the body directly via getInputStream()

 or getReader()

can
interfere with the execution of this method."

According to my understanding of the original Tomcat request code,
Request.getParam depends on Request.parseParameters which in turn uses
Request.readPostBody that uses Request.getStream to obtain the data.
getStream also fetches the inputStream of a request so I believe it won't
work in combination with a call to getReader.

Since your wrapper is not overwriting any method like getParam
(getParameterNames, getParameterValues, getParameterMap) I believe these
methods will still behave incorrectly when called by the target application.

I could indeed build a wrapper that would overwrite getStream, getReader,
getInputStream, getParam, getParameterNames, etc. But then I would be
generating a lot of duplicate code. Since my implementation is purely
experimental I don't think it's such big of a problem to modify Tomcat
internals (the Connector class).

Roel

2015-12-09 18:06 GMT+01:00 Christopher Schultz :

> Roel,
>
> On 12/9/15 8:03 AM, 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.
>
> What you want to do can be done with a Valve as long as you don't mind a
> bit of typing.
>
> See this thread where I built pretty much exactly what you're requesting:
> http://tomcat.markmail.org/thread/fumpfuspt7a3nesz
>
> I implemented mine as a Filter, not as a Valve.
>
> There's no need to go writing your own Request implementation.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Custom Connector class

[Mark Thomas]

On 09/12/2015 11:13, Roel Storms wrote:
> Hello,
> 
> In Tomcat 4.1 it used to be possible to specify a custom class for the
> Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
> 
> In the newest versions it's only possible to provide a custom Protocol.
> However I would like to modify the Request that is created by the
> Connector.createRequest() method. Is this no longer possible via
> configuration?

Currently, this is not possible and hasn't been for quite some time
(over a decade).

What is your real requirement? Or in other words, what requirement are
you trying to meet by replacing the Request implementation?

Mark


-
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 14:13 GMT+03:00 Roel Storms :
> Hello,
>
> In Tomcat 4.1 it used to be possible to specify a custom class for the
> Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
>
> In the newest versions it's only possible to provide a custom Protocol.
> However I would like to modify the Request that is created by the
> Connector.createRequest() method. Is this no longer possible via
> configuration?
>


As a note:
If such a feature ever going to be implemented, the place to fix is
org.apache.catalina.startup.ConnectorCreateRule class.

Instances of Connector are created via that rule, instead of a
standard class creation rule, and so (unlike other elements processed
by digester) className attribute does not work here.

Best regards,
Konstantin Kolinko

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

Re: Custom Connector class

[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 ?





2015-12-09 13:07 GMT+01:00 Konstantin Kolinko :


2015-12-09 14:13 GMT+03:00 Roel Storms :

Hello,

In Tomcat 4.1 it used to be possible to specify a custom class for the
Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html

In the newest versions it's only possible to provide a custom Protocol.
However I would like to modify the Request that is created by the
Connector.createRequest() method. Is this no longer possible via
configuration?




As a note:
If such a feature ever going to be implemented, the place to fix is
org.apache.catalina.startup.ConnectorCreateRule class.

Instances of Connector are created via that rule, instead of a
standard class creation rule, and so (unlike other elements processed
by digester) className attribute does not work here.

Best regards,
Konstantin Kolinko

-
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: Custom Connector class

[Roel Storms]

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.


2015-12-09 13:07 GMT+01:00 Konstantin Kolinko :

> 2015-12-09 14:13 GMT+03:00 Roel Storms :
> > Hello,
> >
> > In Tomcat 4.1 it used to be possible to specify a custom class for the
> > Connector: https://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html
> >
> > In the newest versions it's only possible to provide a custom Protocol.
> > However I would like to modify the Request that is created by the
> > Connector.createRequest() method. Is this no longer possible via
> > configuration?
> >
>
>
> As a note:
> If such a feature ever going to be implemented, the place to fix is
> org.apache.catalina.startup.ConnectorCreateRule class.
>
> Instances of Connector are created via that rule, instead of a
> standard class creation rule, and so (unlike other elements processed
> by digester) className attribute does not work here.
>
> Best regards,
> Konstantin Kolinko
>
> -
> 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/9/15 8:03 AM, 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.

What you want to do can be done with a Valve as long as you don't mind a
bit of typing.

See this thread where I built pretty much exactly what you're requesting:
http://tomcat.markmail.org/thread/fumpfuspt7a3nesz

I implemented mine as a Filter, not as a Valve.

There's no need to go writing your own Request implementation.

-chris

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