Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

Ok, thank you for the clear response. I see the problem with file type
elements.

2015-11-23 17:18 GMT+01:00 André Warnier (tomcat) :

> On 23.11.2015 16:31, Mark Thomas wrote:
>
>> On 23/11/2015 14:30, Roel Storms wrote:
>>
>>> Hello,
>>>
>>> I am working on a Valve that does some integrity checking on HTTP
>>> requests
>>> (the details aren't important) where I need this valve to have access to
>>> the HTTP request body as well. I used request.getInputStream to fetch the
>>> data. However when a web application makes use of my valve, the
>>> getParameter method does not return the parameters submitted via POST
>>> anymore. This is documented behavior according to the spec of
>>> ServletRequest (
>>>
>>> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
>>> ).
>>>
>>> I was wondering why it was designed this way,
>>>
>>
>> Given the potential size of a request body, streaming is the only viable
>> option.
>>
>> since numerous complaints
>>> have arisen from this behavior and some ugly workarounds have been
>>> devised
>>> which unfortunately stop working from Tomcat 7 (servlet 3.0):
>>>
>>>
>>> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
>>>
>>> This shows how easily code like this could break.
>>>
>>
>> What that shows is the folks haven't thought through what they are
>> trying to do. Consider the following:
>>
>> Tomcat provides request R.
>> Filter reads request body using R.getInputStream().
>> Filter caches request body.
>> Filter wraps request R to provide R', over-riding getInputStream() to
>> provide the cached body.
>> Filter passes R' to the application.
>> Application calls R'.getParameter()
>> R'.getParameter() calls R.getParameter()
>>
>> Keep in mind at this point R has zero knowledge of R'.
>>
>> R calls getInputStream() to read request body but that InputStream has
>> already been read.
>>
>> The problem is the wrapper, R'. Over-riding getInputStream() is not
>> enough. It needs to over-ride every method that may access that
>> InputStream. Which is non-trivial because it means re-implementing a lot
>> of functionality the container would normally provide for you out of the
>> box.
>>
>> Overwriting getInputStream to return a cached version doesn't work anymore
>>>
>>
>> Nope. That never worked. See my explanation above.
>>
>> since the parameter attribute isn't populated by using getInputStream. How
>>> exactly it is populated remains a mystery to me. Any advice on how to
>>> solve
>>> this properly?
>>>
>>
>> Write a better wrapper.
>>
>> Performing an integrity check without getInputStream or getReader but with
>>> getParameters, will not work if the data submitted is not in the expected
>>> format.
>>>
>>
>> See above.
>>
>> Mark
>>
>>
> To emphasize a point made by Mark above : a POST body can potentially
> contain one or more  elements.  So imagine a POST
> which contains a 50 MB uploaded file.
> You'd need to read it once (for your Valve) and cache it, then re-read the
> cached version to parse it for parameters.  That would have a serious
> impact on performance.
> (That's what Mark means by "streaming..").
> And because it is a Valve, it would run before the request has been mapped
> to any application, so the hit would be for all applications in the server.
>
> (Of course, in some authentication scenarios, this already happens behind
> the scenes.  But you can avoid it by designing the application accordingly.
> See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html -->
> Common Attributes --> maxSavePostSize)
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Modsecurity - REQBODY ERROR

[tomcat]

On 23.11.2015 10:52, Yogesh Patel wrote:

In modsecurity we have a rule below:

"SecRule REQBODY_ERROR "!@eq 0" \
"id:'21', phase:2,t:none,log,deny,status:400,msg:'Failed to parse
request body.',logdata:'%{reqbody_error_msg}',severity:2"


in mod security log following error message is detected:

"Message: Access denied with code 400 (phase 2). Match of "eq 0"
against "REQBODY_ERROR" required. [file
"D:/tools/Apache2.4.x/conf/extra/highq/modsec/modsecurity.conf"] [line
"132"] [id "21"] [msg "Failed to parse request body."] [data
"Error reading request body: Client went away."] [severity "CRITICAL"]
Action: Intercepted (phase 2)"


What could be the possible reason for this error?



I don't know, but I believe that you may have posted this to the wrong list.
Should you not be sending this to the *Apache httpd* user list, instead of the *Apache 
Tomcat* user list ?

See : http://httpd.apache.org/ versus http://tomcat.apache.org
(They both belong to the Apache organisation, but they are different software 
products)
And modsecurity is yet another separate thing, at http://www.modsecurity.org, but it seems 
more related to Apache httpd than to Tomcat.



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

Re: Source IP filtering on some URLs before Container-managed authentication

[Ognjen Blagojevic]

Andre,

On 20.11.2015 17:44, André Warnier (tomcat) wrote:

Well, you can use a lot more conditions in urlrewrite filter, such as a
client IP + URL patterns + lots more. And you can combine them using the
type="next".

Your original post said "My webapp have a set of resources, let's call
that set R. Some of those resources need to be accessed only from
certain source IP addresses, let's call that subset R'. And some subset
of R' (let's call it R'') needs authentication."

So if I get this correctly,
for R'' you have 3 requirements :
- a URL matching R'' (check with "request-url" or "request-uri")
- a remote IP (check with "remote_addr")
- an authenticated user (check with "remote_user" not blank)
  and if it does not match the last 2, return "not found" or "forbidden"
or a login page
  (or anything else that strikes your fancy)


Thanks for calrifying. I am using urlrewritefilter, for some basic 
stuff, but I will take a look if it can also be used for this scenario.


-Ognjen

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

Modsecurity - REQBODY ERROR

[Yogesh Patel]

In modsecurity we have a rule below:

"SecRule REQBODY_ERROR "!@eq 0" \
"id:'21', phase:2,t:none,log,deny,status:400,msg:'Failed to parse
request body.',logdata:'%{reqbody_error_msg}',severity:2"


in mod security log following error message is detected:

"Message: Access denied with code 400 (phase 2). Match of "eq 0"
against "REQBODY_ERROR" required. [file
"D:/tools/Apache2.4.x/conf/extra/highq/modsec/modsecurity.conf"] [line
"132"] [id "21"] [msg "Failed to parse request body."] [data
"Error reading request body: Client went away."] [severity "CRITICAL"]
Action: Intercepted (phase 2)"


What could be the possible reason for this error?

-- 
*Thanks & Regards,*

* Yogesh Patel*

Fwd:

[Yuval Schwartz]

Hello,

I am using tomcat 8.0.22.0
Language: Java
development: Windows, NetBeans.
deployment: ec2 linux

I am still having trouble understanding/working with "path" and "docBase"
of context element.
I have two questions:

First of all, I have a context.xml file in the WEB-INF folder of my
application (call it "myApplication" henceforth) that looks like:





My context path is set to the empty string because once I set up a domain
name it will be redundant to have both the application name and domain name
in the url (they are the same).

This works on my development environment.

When I deploy this to a linux server of an ec2 instance (on aws) I add a
line to the server.xml file (in tomcat/conf) under the  element which
reads:


(If I don't add this element to the server.xml file then entering just the
domain in the url takes me to the Apache Tomcat "successful installation"
page rather than to the welcome page of myApplication).

First question:
Is this the correct way to set up tomcat so that my application has no
context path? Not sure if this leads to the "double deployment" problem or
not. When I open the tomcat manager I see two applications: one with path:
"/" and the other with path "/myApplication". (for some reason, I don't
have the option to "undeploy" the application with path: "/")

Second question:
The resource element within the context element of my context.xml file
(located in WEB-INF) specifies a url that is specific to my development (ie
local) environment.
When I deploy myApplication to the ec2 instance I would like the resource
element to have a different url attribute (since it will now be connecting
with a database on an aws server).
One way that I found to do this was to add to the context.xml file in the
tomcat/conf directory of my server. There I add a resource element (between
the existing context element) which is identical to the one above only with
a url attribute that points to the database hosted on aws.

This way, my application is able to connect with my database without me
changing any of the code in myApplication.
However, my Catalina.log file displays:
WARNING [localhost-startStop-1]
org.apache.catalina.core.NamingContextListener.add Resource Failed to
register in JMX: javax.naming.NamingException: Could not create resource
factory instance [Root exception is java.lang.ClassNotFoundException:
org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory]

And my localhost.log file shows a nullpointerexception for the line in my
code:
ic.lookup("java:comp/env/jdbc/some_db");
(Where ic is an InitialContext Object)

There are also problems in the deployed website with some of the code that
grabs data from the db (but some of the db related code works successfully).

Any insight or suggestions would be greatly appreciated.
I'm new to a lot of this (extremely new to deploying to a server).

Thank you
_

ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

Hello,

I am working on a Valve that does some integrity checking on HTTP requests
(the details aren't important) where I need this valve to have access to
the HTTP request body as well. I used request.getInputStream to fetch the
data. However when a web application makes use of my valve, the
getParameter method does not return the parameters submitted via POST
anymore. This is documented behavior according to the spec of
ServletRequest (
https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
).

I was wondering why it was designed this way, since numerous complaints
have arisen from this behavior and some ugly workarounds have been devised
which unfortunately stop working from Tomcat 7 (servlet 3.0):

https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once

This shows how easily code like this could break.

Overwriting getInputStream to return a cached version doesn't work anymore
since the parameter attribute isn't populated by using getInputStream. How
exactly it is populated remains a mystery to me. Any advice on how to solve
this properly?

Performing an integrity check without getInputStream or getReader but with
getParameters, will not work if the data submitted is not in the expected
format.

Kind regards,

Roel Storms

Re: ServletRequest.getInputStream, getReader, getParameter.

[tomcat]

On 23.11.2015 21:14, Roel Storms wrote:

Ok, thank you for the clear response. I see the problem with file type
elements.


If you really have an overwhelming need to pre-check whole POST bodies before passing them 
to a Tomcat application, you may want to think about fronting your Tomcat server with an 
Apache httpd server.  You could then do the checking at the Apache httpd level, before 
forwarding the request to Tomcat. And of course not forward it at all if the check fails.
Doing this at the front-end level would not "consume" the request body, as it does when 
you do this under Tomcat.
All in all, you would still end up reading the request body twice.  But depending on your 
use case, it may be worth it.


In your initial post below, you wrote "..some integrity checking on HTTP
requests (the details aren't important)..".
But if you want further help or recommendations, I believe that more details about what 
exactly you are trying to achieve and/or check, would be important.
After all, Tomcat is already making a fair amount of checking by default, on any received 
HTTP request, before it will forward it to any application.  So it would be interesting to 
have an idea of which extra checks you want to make.





2015-11-23 17:18 GMT+01:00 André Warnier (tomcat) :


On 23.11.2015 16:31, Mark Thomas wrote:


On 23/11/2015 14:30, Roel Storms wrote:


Hello,

I am working on a Valve that does some integrity checking on HTTP
requests
(the details aren't important) where I need this valve to have access to
the HTTP request body as well. I used request.getInputStream to fetch the
data. However when a web application makes use of my valve, the
getParameter method does not return the parameters submitted via POST
anymore. This is documented behavior according to the spec of
ServletRequest (

https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
).

I was wondering why it was designed this way,



Given the potential size of a request body, streaming is the only viable
option.

since numerous complaints

have arisen from this behavior and some ugly workarounds have been
devised
which unfortunately stop working from Tomcat 7 (servlet 3.0):


https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once

This shows how easily code like this could break.



What that shows is the folks haven't thought through what they are
trying to do. Consider the following:

Tomcat provides request R.
Filter reads request body using R.getInputStream().
Filter caches request body.
Filter wraps request R to provide R', over-riding getInputStream() to
provide the cached body.
Filter passes R' to the application.
Application calls R'.getParameter()
R'.getParameter() calls R.getParameter()

Keep in mind at this point R has zero knowledge of R'.

R calls getInputStream() to read request body but that InputStream has
already been read.

The problem is the wrapper, R'. Over-riding getInputStream() is not
enough. It needs to over-ride every method that may access that
InputStream. Which is non-trivial because it means re-implementing a lot
of functionality the container would normally provide for you out of the
box.

Overwriting getInputStream to return a cached version doesn't work anymore




Nope. That never worked. See my explanation above.

since the parameter attribute isn't populated by using getInputStream. How

exactly it is populated remains a mystery to me. Any advice on how to
solve
this properly?



Write a better wrapper.

Performing an integrity check without getInputStream or getReader but with

getParameters, will not work if the data submitted is not in the expected
format.



See above.

Mark



To emphasize a point made by Mark above : a POST body can potentially
contain one or more  elements.  So imagine a POST
which contains a 50 MB uploaded file.
You'd need to read it once (for your Valve) and cache it, then re-read the
cached version to parse it for parameters.  That would have a serious
impact on performance.
(That's what Mark means by "streaming..").
And because it is a Valve, it would run before the request has been mapped
to any application, so the hit would be for all applications in the server.

(Of course, in some authentication scenarios, this already happens behind
the scenes.  But you can avoid it by designing the application accordingly.
See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html -->
Common Attributes --> maxSavePostSize)




-
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 Conflicting with Group Policy Client

[Nick Childs]

I did some testing with the PostgreSQL max_connections parameter this 
afternoon, but this does not solve our problem unfortunately. 

Set max_connections to 300 (was 100), and rebooted the server. Verified that 
gpupdate is unable to complete if PostgreSQL is able to communicate with 
Tomcat. 

Does anyone have any other ideas on what I can check to flush this out from 
Tomcat's side? 


Regards,

Nick Childs
Information Technology Manager
RamSoft USA, Inc. 
9480 Utica Avenue, Suite 612
Rancho Cucamonga, CA 91730
Phone: 909.481.5800 x115
Cell: 909.717.4078
Skype: nchilds.ramsoft
Email: nchi...@ramsoft.com




-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Thursday, November 19, 2015 1:35 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Conflicting with Group Policy Client

On 19.11.2015 05:19, Nick Childs wrote:
> Tomcat Version: 6.0.39
>
> Operating System: Server 2012 R2 Standard
>
> Configuration: We are utilizing Tomcat as part of a Pentaho deployment - 
> Tomcat is utilized for Pentaho's Data Integration and Business Analytics 
> services.
> Description: We have a custom Deployment of Pentaho using PostgreSQL and 
> Tomcat Apache running within the current version of our proprietary Medical 
> Imaging software. The integration works well, but we have spent months 
> struggling to identify the cause of a major conflict between the 
> PostgreSQL/Tomcat integration and group policy client in windows domain 
> environments. Whenever the PostgreSQL and Tomcat Apache (Pentaho Data 
> Integration) services are running, we begin to see 1 hour + reboot times and 
> gpupdate failures due to the group policy client just hanging for long 
> periods of time with no explanation. If only Pentaho is running, no problem 
> is experienced. If only Tomcat is running, no problem is experienced - it is 
> only when we have both running/communicating the Group Policy updates begin 
> to fail.
>
> We have enabled all known debugging in Group Policy, PostgreSQL, Pentaho, and 
> Tomcat, performed xBootMgr traces, performed Process Monitor analysis, and 
> Packet Captures, but have been unable to determine the cause of the conflict. 
> We are also working with Microsoft, Pentaho, and PostgreSQL independently to 
> try and flush out the culprit. After spending weeks analyzing and reviewing 
> our development team's internal notes, I have become fairly confident that 
> the root cause of this problem is related to the way that we deployed Tomcat, 
> and the way that Tomcat/PostgreSQL communicate with each other, but I have 
> not found solid proof that actually indicates this yet.
>
> I have learned a lot about how PostgreSQL/Tomcat are functioning in this 
> environment over the last week, but I am not part of the team that deployed 
> this, and am certainly not an expert on Pentaho, PostgreSQL, or Tomcat. I 
> have been collecting a list of debug error/warnings from the Tomcat logs over 
> the last few days (attached), and I am hoping someone who is an expert on 
> this stuff can possibly review this list of errors, provide an 
> explanation/priority for each, and answer the following questions:
>
> 1. Are there any known conflicts with Tomcat and GroupPolicy in Windows 
> domain environments? Required Configurations? Workarounds?
> 3. Are there any special debugging options or monitoring tools that we could 
> use to get more information about what Tomcat is doing during the time 
> periods that Group Policy Client is hung? The built-in logging is not helping 
> us.
> 4. Do you have any suggestions or options that we can try to see if our 
> behavior changes?
>
> Please let me know if there is any additional information I can provide to 
> help.
>

Hi.
I don't know anything about the various non-Tomcat softwares you are 
mentioning, and just a little bit about Tomcat.
But the one thing I see in your Tomcat logfile, is that there seem to be a lot 
of TCP connection errors of the kind "(Connection refused. Check that the 
hostname and port are correct and that the postmaster is accepting TCP/IP 
connections.)"
These seem to be related mostly to PostgreSQL.
Maybe there is a limit (in the PostgreSQL configuration) to how many 
connections it accepts at the same time ? or maybe the PostgreSQL server is 
just overloaded ?
Anyway, I would check this first, because there is a chance that many of the 
other errors which you are seeing are cascading down from there.



-
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: ServletRequest.getInputStream, getReader, getParameter.

[Mark Thomas]

On 23/11/2015 14:30, Roel Storms wrote:
> Hello,
> 
> I am working on a Valve that does some integrity checking on HTTP requests
> (the details aren't important) where I need this valve to have access to
> the HTTP request body as well. I used request.getInputStream to fetch the
> data. However when a web application makes use of my valve, the
> getParameter method does not return the parameters submitted via POST
> anymore. This is documented behavior according to the spec of
> ServletRequest (
> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
> ).
> 
> I was wondering why it was designed this way,

Given the potential size of a request body, streaming is the only viable
option.

> since numerous complaints
> have arisen from this behavior and some ugly workarounds have been devised
> which unfortunately stop working from Tomcat 7 (servlet 3.0):
> 
> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
> 
> This shows how easily code like this could break.

What that shows is the folks haven't thought through what they are
trying to do. Consider the following:

Tomcat provides request R.
Filter reads request body using R.getInputStream().
Filter caches request body.
Filter wraps request R to provide R', over-riding getInputStream() to
provide the cached body.
Filter passes R' to the application.
Application calls R'.getParameter()
R'.getParameter() calls R.getParameter()

Keep in mind at this point R has zero knowledge of R'.

R calls getInputStream() to read request body but that InputStream has
already been read.

The problem is the wrapper, R'. Over-riding getInputStream() is not
enough. It needs to over-ride every method that may access that
InputStream. Which is non-trivial because it means re-implementing a lot
of functionality the container would normally provide for you out of the
box.

> Overwriting getInputStream to return a cached version doesn't work anymore

Nope. That never worked. See my explanation above.

> since the parameter attribute isn't populated by using getInputStream. How
> exactly it is populated remains a mystery to me. Any advice on how to solve
> this properly?

Write a better wrapper.

> Performing an integrity check without getInputStream or getReader but with
> getParameters, will not work if the data submitted is not in the expected
> format.

See above.

Mark


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

Re: ServletRequest.getInputStream, getReader, getParameter.

[tomcat]

On 23.11.2015 16:31, Mark Thomas wrote:

On 23/11/2015 14:30, Roel Storms wrote:

Hello,

I am working on a Valve that does some integrity checking on HTTP requests
(the details aren't important) where I need this valve to have access to
the HTTP request body as well. I used request.getInputStream to fetch the
data. However when a web application makes use of my valve, the
getParameter method does not return the parameters submitted via POST
anymore. This is documented behavior according to the spec of
ServletRequest (
https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
).

I was wondering why it was designed this way,


Given the potential size of a request body, streaming is the only viable
option.


since numerous complaints
have arisen from this behavior and some ugly workarounds have been devised
which unfortunately stop working from Tomcat 7 (servlet 3.0):

https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once

This shows how easily code like this could break.


What that shows is the folks haven't thought through what they are
trying to do. Consider the following:

Tomcat provides request R.
Filter reads request body using R.getInputStream().
Filter caches request body.
Filter wraps request R to provide R', over-riding getInputStream() to
provide the cached body.
Filter passes R' to the application.
Application calls R'.getParameter()
R'.getParameter() calls R.getParameter()

Keep in mind at this point R has zero knowledge of R'.

R calls getInputStream() to read request body but that InputStream has
already been read.

The problem is the wrapper, R'. Over-riding getInputStream() is not
enough. It needs to over-ride every method that may access that
InputStream. Which is non-trivial because it means re-implementing a lot
of functionality the container would normally provide for you out of the
box.


Overwriting getInputStream to return a cached version doesn't work anymore


Nope. That never worked. See my explanation above.


since the parameter attribute isn't populated by using getInputStream. How
exactly it is populated remains a mystery to me. Any advice on how to solve
this properly?


Write a better wrapper.


Performing an integrity check without getInputStream or getReader but with
getParameters, will not work if the data submitted is not in the expected
format.


See above.

Mark



To emphasize a point made by Mark above : a POST body can potentially contain one or more 
 elements.  So imagine a POST which contains a 50 MB uploaded file.
You'd need to read it once (for your Valve) and cache it, then re-read the cached version 
to parse it for parameters.  That would have a serious impact on performance.

(That's what Mark means by "streaming..").
And because it is a Valve, it would run before the request has been mapped to any 
application, so the hit would be for all applications in the server.


(Of course, in some authentication scenarios, this already happens behind the scenes.  But 
you can avoid it by designing the application accordingly.
See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html --> Common Attributes --> 
maxSavePostSize)




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

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

2015-11-23 16:31 GMT+01:00 Mark Thomas :

> On 23/11/2015 14:30, Roel Storms wrote:
> > Hello,
> >
> > I am working on a Valve that does some integrity checking on HTTP
> requests
> > (the details aren't important) where I need this valve to have access to
> > the HTTP request body as well. I used request.getInputStream to fetch the
> > data. However when a web application makes use of my valve, the
> > getParameter method does not return the parameters submitted via POST
> > anymore. This is documented behavior according to the spec of
> > ServletRequest (
> >
> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
> > ).
> >
> > I was wondering why it was designed this way,
>
> Given the potential size of a request body, streaming is the only viable
> option.
>
> > since numerous complaints
> > have arisen from this behavior and some ugly workarounds have been
> devised
> > which unfortunately stop working from Tomcat 7 (servlet 3.0):
> >
> >
> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
> >
> > This shows how easily code like this could break.
>
> What that shows is the folks haven't thought through what they are
> trying to do. Consider the following:
>
> Tomcat provides request R.
> Filter reads request body using R.getInputStream().
> Filter caches request body.
> Filter wraps request R to provide R', over-riding getInputStream() to
> provide the cached body.
> Filter passes R' to the application.
> Application calls R'.getParameter()
> R'.getParameter() calls R.getParameter()
>
> Keep in mind at this point R has zero knowledge of R'.
>
> R calls getInputStream() to read request body but that InputStream has
> already been read.
>
> The problem is the wrapper, R'. Over-riding getInputStream() is not
> enough. It needs to over-ride every method that may access that
> InputStream. Which is non-trivial because it means re-implementing a lot
> of functionality the container would normally provide for you out of the
> box.
>
> > Overwriting getInputStream to return a cached version doesn't work
> anymore
>
> Nope. That never worked. See my explanation above.
>
> > since the parameter attribute isn't populated by using getInputStream.
> How
> > exactly it is populated remains a mystery to me. Any advice on how to
> solve
> > this properly?
>
> Write a better wrapper.
>
> A better wrapper would need to implement every method using the stream. To
get a correct output from parseParameters it doesn't suffice to override
readPostBody and readChunkedPostBody since these are overridden in the
wrapper but the implementation of parseParameter in the Request won't use
them. Overriding parseParameters as well, can't be done since it uses a lot
of protected flags (parametersParsed, usingInputStream, usingReader,...).
This would mean overriding almost the entire Request. Every time you need a
protected attribute or operation in your overriding implementation, you
need to override this attribute and operation as well. In the end you would
copy almost the entire request.

> Performing an integrity check without getInputStream or getReader but with
> > getParameters, will not work if the data submitted is not in the expected
> > format.
>
> See above.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re:

[Yuval Schwartz]

Update regarding my second question below...The first question is still
valid as is and I am still interested in input.

On Mon, Nov 23, 2015 at 3:38 PM, Yuval Schwartz 
wrote:

> Hello,
>
> I am using tomcat 8.0.22.0
> Language: Java
> development: Windows, NetBeans.
> deployment: ec2 linux
>
> I am still having trouble understanding/working with "path" and "docBase"
> of context element.
> I have two questions:
>
> First of all, I have a context.xml file in the WEB-INF folder of my
> application (call it "myApplication" henceforth) that looks like:
>
> 
>  maxActive="100" maxIdle="30" maxWait="1"
> username="blah" password="blahblah"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://localhost:3306/some_db?autoReconnect=true"
> logAbandoned="true" removeAbandoned="true"
> removeAbandonedTimeout="60" type="javax.sql.DataSource" />
> 
>
> My context path is set to the empty string because once I set up a domain
> name it will be redundant to have both the application name and domain name
> in the url (they are the same).
>
> This works on my development environment.
>
> When I deploy this to a linux server of an ec2 instance (on aws) I add a
> line to the server.xml file (in tomcat/conf) under the  element which
> reads:
> 
>
> (If I don't add this element to the server.xml file then entering just the
> domain in the url takes me to the Apache Tomcat "successful installation"
> page rather than to the welcome page of myApplication).
>
> First question:
> Is this the correct way to set up tomcat so that my application has no
> context path? Not sure if this leads to the "double deployment" problem or
> not. When I open the tomcat manager I see two applications: one with path:
> "/" and the other with path "/myApplication". (for some reason, I don't
> have the option to "undeploy" the application with path: "/")
>
> Second question:
> The resource element within the context element of my context.xml file
> (located in WEB-INF) specifies a url that is specific to my development (ie
> local) environment.
> When I deploy myApplication to the ec2 instance I would like the resource
> element to have a different url attribute (since it will now be connecting
> with a database on an aws server).
> One way that I found to do this was to add to the context.xml file in the
> tomcat/conf directory of my server. There I add a resource element (between
> the existing context element) which is identical to the one above only with
> a url attribute that points to the database hosted on aws.
>
> This way, my application is able to connect with my database without me
> changing any of the code in myApplication.
> However, my Catalina.log file displays:
> WARNING [localhost-startStop-1]
> org.apache.catalina.core.NamingContextListener.add Resource Failed to
> register in JMX: javax.naming.NamingException: Could not create resource
> factory instance [Root exception is java.lang.ClassNotFoundException:
> org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory]
>
> And my localhost.log file shows a nullpointerexception for the line in my
> code:
> ic.lookup("java:comp/env/jdbc/some_db");
> (Where ic is an InitialContext Object)
>
> There are also problems in the deployed website with some of the code that
> grabs data from the db (but some of the db related code works successfully).
>

It turns out that these warning and exceptions were caused because of
missing jar files in the JDK's jre/lib/ext folder.

tomcat-dbcp.jar is not available in amazon's tomcat8 AMI (my terminology
might be a bit off).

Instead, one needs to transfer both the commons-dbcp.jar and
commons-pool.jar from tomcat/lib into the JDK's jre/lib/ext folder
In addition, since this is not the default factory in the Resource element
that I declared (as was the case with tomcat-jdbc), you need to explicitly
specify it: factory="org.apache.commons.dbcp.BasicDataSourceFactory"


>
> Any insight or suggestions would be greatly appreciated.
> I'm new to a lot of this (extremely new to deploying to a server).
>
> Thank you
> _
>
>
>
>
>
>
>