You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by M4N - Arjan Tijms <ar...@mbuyu.nl> on 2007/08/24 18:43:27 UTC
Tomcat looses POST parameters
Hi,
We're hosting a fairly high traffic web application based on Tomcat.
It's running on Debian-Etch, JDK 5.0U10 and Tomcat 5.5.20. We're using
Apache as a front-end with the AJP connector.
The problem I'm encountering is that for a percentage of the POST
requests, Tomcat seems to loose all parameters. Our application uses a
filter that logs the (first few characters of) post parameters. This
filter is installed as the first one in the filter chain, so nothing
else can interfere with it. For requests originating from pages which
logically can not produce such an empty post request, the log clearly
shows there are no parameters.
The problem is often fairly random, although I have been able to
consistently reproduce it on one occasion. Using a proxy server to
monitor what my browser was sending, I clearly saw in the raw HTTP
headers that parameters where being send, yet they weren't received in
Tomcat. I also enabled TCP/IP packet logging at the server for a while.
For requests that appeared with empty parameters in Tomcat, the tcp/ip
log showed the parameters did arrive at the server.
Next to that I enabled debug logging in the AJP connector, and again the
POST parameters were in the HTTP request but not present when the
mentioned filter logged the request in Tomcat.
I did notice though that the overwhelming majority of the "empty post"
requests concerned Faces requests (we're using MyFaces 1.1.4). We store
state on client, so typical Faces HTTP post requests are at least 22KB
in size. Nevertheless, thousands of requests from the same pages from
all kinds of different browsers arrive with the post parameters intact.
I'm at a loss here how to proceed. Naturally I could change JSF to keep
state on server, but because of the way some custom components work
that's currently not an option. It would also not really solve the
underlying problem of course.
Any help would be greatly appreciated
Kind regards,
Arjan Tijms
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by David Delbecq <de...@oma.be>.
Just a point worth if it's related to FORM login; The form login does
have a maximum request size that is stored in user session and restored
after login as original request. If request was too big (fileupload,
article submissions, etc), it might get dropped. I think the default max
is about 100K.
Also, check it's not the user having something like fasterfox or another
web "accelerator" installed. Those are agressive and can sometimes mess
up navigation.
As also suggested, if you have apache front end, check it does not have
some special configuration that would drop parameter at some point. And
check there is no proxy / active firewall that could badly alter request...
And check it's not simply user typing "enter" in url bar to refresh a
POST page :)
Christopher Schultz a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Arjan,
>
> M4N - Arjan Tijms wrote:
>
>> It's a good thought, and such a thing could have happened. Only in this
>> case the parameters are already missing before any request processing is
>> being done.
>>
>
> No, your filter will only be executed after the login has been handled,
> since Tomcat's authentication is done using a valve, which is processed
> before any filters.
>
> If you are experiencing it yourself directly, you can verify that it
> happens even when a login is not involved.
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG0yf79CaO5/Lv0PARAuXEAJ9+knXYy6mNmilh2dgWeSfmRoT/OACeI8ev
> 63G7rl+mlc5glAWDnuhxM7M=
> =hb97
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan,
M4N - Arjan Tijms wrote:
> Christopher Schultz wrote:
>
>> Uh, I'm not really sure what you're saying, here. TCs auth code /will/
>> run before any of your code if you are using it.
>>
> Of course, but that's exactly what I'm saying. If Tomcat's auth code
> runs first, than the possible error would be in Tomcat's code.
Yes, but you're not using Tomcat for authentication, so Tomcat's code
/never/ runs.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1F1o9CaO5/Lv0PARAgenAKCz1f9XeVxIBmiGftOJTbtp1+ARwwCdHKnb
qfiatEk+8Ba/N3nsJDlbbYw=
=YzGD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Christopher Schultz wrote:
>Uh, I'm not really sure what you're saying, here. TCs auth code /will/
>run before any of your code if you are using it.
>
Of course, but that's exactly what I'm saying. If Tomcat's auth code
runs first, than the possible error would be in Tomcat's code.
>Do you implement authentication and authorization as a filter? Or, do
>you have something else going on? I'm asking because it's possible your
>own authentication mechanism has a bug or two that is somehow killing
>the request parameters.
>
>
The custom authentication method is filter based. I installed the filter
that prints the request parameters to the log as the very first filter
in the chain; this means it gets called before any other filter does.
So, the logging is the very first piece of my code that gets called when
processing a single request.
Like I said earlier: in the AJP connector the parameters are there and
at the first opportunity that my own code can run they are gone. They
get lost somewhere in between. Since none of my code runs in between,
it's hard to say what happens. I might try building a debug Tomcat that
does some extra logging at key points in the request handling, but for a
high volume production server this would really be my last resort.
Kind regards,
Arjan Tijms
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan,
M4N - Arjan Tijms wrote:
> Christopher Schultz wrote:
>> No, your filter will only be executed after the login has been handled,
>> since Tomcat's authentication is done using a valve, which is processed
>> before any filters.
>
> I see. The thing is, I'm not using any container managed authentication
> at all. All authentication is handled by the application.
Oh, well, that's different, then ;)
> But even if I
> used the container's (Tomcat's) authentication, then it still would be
> Tomcat's code than ran before my code, right?
Uh, I'm not really sure what you're saying, here. TCs auth code /will/
run before any of your code if you are using it. Since you're not, your
own auth code will run whenever you have configured it to do so.
Do you implement authentication and authorization as a filter? Or, do
you have something else going on? I'm asking because it's possible your
own authentication mechanism has a bug or two that is somehow killing
the request parameters.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1CG79CaO5/Lv0PARAnCgAJ4pAKGKhNWpnd1FMl1vut8flBZ+MACgglvW
otYD3KMYiEZ7kw4dDuMs+dI=
=tPZ6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Hi,
Christopher Schultz wrote:
>No, your filter will only be executed after the login has been handled,
>since Tomcat's authentication is done using a valve, which is processed
>before any filters.
>
>
I see. The thing is, I'm not using any container managed authentication
at all. All authentication is handled by the application. But even if I
used the container's (Tomcat's) authentication, then it still would be
Tomcat's code than ran before my code, right?
Grtz,
Arjan Tijms
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan,
M4N - Arjan Tijms wrote:
> It's a good thought, and such a thing could have happened. Only in this
> case the parameters are already missing before any request processing is
> being done.
No, your filter will only be executed after the login has been handled,
since Tomcat's authentication is done using a valve, which is processed
before any filters.
If you are experiencing it yourself directly, you can verify that it
happens even when a login is not involved.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG0yf79CaO5/Lv0PARAuXEAJ9+knXYy6mNmilh2dgWeSfmRoT/OACeI8ev
63G7rl+mlc5glAWDnuhxM7M=
=hb97
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Hi,
Christopher Schultz wrote:
>>The problem I'm encountering is that for a percentage of the POST
>>requests, Tomcat seems to loose all parameters.
>>
>>
>
>Are you observing this in log files, or by actually doing it and having
>it fail.
>
Both actually.
I have installed a top-level filter, and the very first thing it does
when its doFilter method is being called is calling
request.getParameterMap(), iterating over its values, and logging the
name and first chars of each parameter. Logging happens to a standard
java.Util.logging.Logger.
Before this filter is being called, none of my own code has been
executed in the context of the current request.
After that, if the page required a specific parameter an error is being
generated. This indeed happens. Other pages ignore the request if
parameters are missing. I have observed this too.
>I'm wondering if
>something is happening to the saved request during the login.
>
>
It's a good thought, and such a thing could have happened. Only in this
case the parameters are already missing before any request processing is
being done. Also, 99.9% of the requests execute well, only in 0.1 orso
the parameters are missing. That doesn't sound like much but 0.1% of a
high traffic site is still a lot of requests. (I made the 0.1 number up
and haven't calculated it exactly, but it's a small number)
Kind regards,
Arjan Tijms
>Just looking for other possibilities.
>
>- -chris
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.7 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFG0vPr9CaO5/Lv0PARAkCpAKCjmbuGvcENYdmmeJ0I64AJuBsjlgCgri5D
>9BOdjvmdWbarm3liy6EHjfk=
>=GbyQ
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan,
M4N - Arjan Tijms wrote:
> The problem I'm encountering is that for a percentage of the POST
> requests, Tomcat seems to loose all parameters.
Are you observing this in log files, or by actually doing it and having
it fail. I'm asking because it might be related to saved requests being
re-processed by Tomcat after a login.
For instance, if the user isn't logged-in and requests a protected
resource, the original request is saved and the login form is presented.
Upon successful login, the original request is resumed. I'm wondering if
something is happening to the saved request during the login.
Just looking for other possibilities.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG0vPr9CaO5/Lv0PARAkCpAKCjmbuGvcENYdmmeJ0I64AJuBsjlgCgri5D
9BOdjvmdWbarm3liy6EHjfk=
=GbyQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Hi,
thebugslayer wrote:
>I would suggest a TCP sniff tool like one found from axis or grinder
>to peek at your http track to be sure.
>
>
Thanks for your reply. The TCP Sniffer from The Grinder is an HTTP
proxy, and I already tried that:
>Using a proxy server to
>monitor what my browser was sending, I clearly saw in the raw HTTP
>headers that parameters where being send, yet they weren't received in
>Tomcat.
>
As I wrote in my original mail, I traced the problem two levels deeper;
both at the TCP/IP level at the server and in the connector between
Apache and Tomcat. Post parameters are still there, but are gone once in
Tomcat.
Grtz,
Arjan Tijms
>On 8/24/07, M4N - Arjan Tijms <ar...@mbuyu.nl> wrote:
>
>
>>Hi,
>>
>>We're hosting a fairly high traffic web application based on Tomcat.
>>It's running on Debian-Etch, JDK 5.0U10 and Tomcat 5.5.20. We're using
>>Apache as a front-end with the AJP connector.
>>
>>The problem I'm encountering is that for a percentage of the POST
>>requests, Tomcat seems to loose all parameters. Our application uses a
>>filter that logs the (first few characters of) post parameters. This
>>filter is installed as the first one in the filter chain, so nothing
>>else can interfere with it. For requests originating from pages which
>>logically can not produce such an empty post request, the log clearly
>>shows there are no parameters.
>>
>>The problem is often fairly random, although I have been able to
>>consistently reproduce it on one occasion. Using a proxy server to
>>monitor what my browser was sending, I clearly saw in the raw HTTP
>>headers that parameters where being send, yet they weren't received in
>>Tomcat. I also enabled TCP/IP packet logging at the server for a while.
>>For requests that appeared with empty parameters in Tomcat, the tcp/ip
>>log showed the parameters did arrive at the server.
>>
>>Next to that I enabled debug logging in the AJP connector, and again the
>>POST parameters were in the HTTP request but not present when the
>>mentioned filter logged the request in Tomcat.
>>
>>I did notice though that the overwhelming majority of the "empty post"
>>requests concerned Faces requests (we're using MyFaces 1.1.4). We store
>>state on client, so typical Faces HTTP post requests are at least 22KB
>>in size. Nevertheless, thousands of requests from the same pages from
>>all kinds of different browsers arrive with the post parameters intact.
>>
>>I'm at a loss here how to proceed. Naturally I could change JSF to keep
>>state on server, but because of the way some custom components work
>>that's currently not an option. It would also not really solve the
>>underlying problem of course.
>>
>>Any help would be greatly appreciated
>>
>>
>>Kind regards,
>>Arjan Tijms
>>
>>--
>>It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
>>
>>
>>---------------------------------------------------------------------
>>To start a new topic, e-mail: users@tomcat.apache.org
>>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>
>
>
>
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Hi,
Martin Gainty wrote:
> Fiddler lets you construct the request
> http://www.fiddlertool.com/fiddler/
Thanks for your suggestion, but I already tried that:
> Using a proxy server to
> monitor what my browser was sending, I clearly saw in the raw HTTP
> headers that parameters where being send
In my case I was using Burpproxy, which seems to do more or less the
same as fiddler.
Grtz,
Arjan Tijms
>
>
> ----- Original Message ----- From: "thebugslayer"
> <th...@gmail.com>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Sent: Sunday, August 26, 2007 8:06 PM
> Subject: Re: Tomcat looses POST parameters
>
>
>> I would suggest a TCP sniff tool like one found from axis or grinder
>> to peek at your http track to be sure.
>>
>> On 8/24/07, M4N - Arjan Tijms <ar...@mbuyu.nl> wrote:
>>
>>> Hi,
>>>
>>> We're hosting a fairly high traffic web application based on Tomcat.
>>> It's running on Debian-Etch, JDK 5.0U10 and Tomcat 5.5.20. We're using
>>> Apache as a front-end with the AJP connector.
>>>
>>> The problem I'm encountering is that for a percentage of the POST
>>> requests, Tomcat seems to loose all parameters. Our application uses a
>>> filter that logs the (first few characters of) post parameters. This
>>> filter is installed as the first one in the filter chain, so nothing
>>> else can interfere with it. For requests originating from pages which
>>> logically can not produce such an empty post request, the log clearly
>>> shows there are no parameters.
>>>
>>> The problem is often fairly random, although I have been able to
>>> consistently reproduce it on one occasion. Using a proxy server to
>>> monitor what my browser was sending, I clearly saw in the raw HTTP
>>> headers that parameters where being send, yet they weren't received in
>>> Tomcat. I also enabled TCP/IP packet logging at the server for a while.
>>> For requests that appeared with empty parameters in Tomcat, the tcp/ip
>>> log showed the parameters did arrive at the server.
>>>
>>> Next to that I enabled debug logging in the AJP connector, and again
>>> the
>>> POST parameters were in the HTTP request but not present when the
>>> mentioned filter logged the request in Tomcat.
>>>
>>> I did notice though that the overwhelming majority of the "empty post"
>>> requests concerned Faces requests (we're using MyFaces 1.1.4). We store
>>> state on client, so typical Faces HTTP post requests are at least 22KB
>>> in size. Nevertheless, thousands of requests from the same pages from
>>> all kinds of different browsers arrive with the post parameters intact.
>>>
>>> I'm at a loss here how to proceed. Naturally I could change JSF to keep
>>> state on server, but because of the way some custom components work
>>> that's currently not an option. It would also not really solve the
>>> underlying problem of course.
>>>
>>> Any help would be greatly appreciated
>>>
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>> --
>>> It's a cult. If you've coded for any length of time, you've run
>>> across someone from this warped brotherhood. Their creed: if you can
>>> write complicated code, you must be good.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> --
>> /bugslayer
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by Martin Gainty <mg...@hotmail.com>.
Fiddler lets you construct the request
http://www.fiddlertool.com/fiddler/
M--
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
----- Original Message -----
From: "thebugslayer" <th...@gmail.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Sunday, August 26, 2007 8:06 PM
Subject: Re: Tomcat looses POST parameters
>I would suggest a TCP sniff tool like one found from axis or grinder
> to peek at your http track to be sure.
>
> On 8/24/07, M4N - Arjan Tijms <ar...@mbuyu.nl> wrote:
>> Hi,
>>
>> We're hosting a fairly high traffic web application based on Tomcat.
>> It's running on Debian-Etch, JDK 5.0U10 and Tomcat 5.5.20. We're using
>> Apache as a front-end with the AJP connector.
>>
>> The problem I'm encountering is that for a percentage of the POST
>> requests, Tomcat seems to loose all parameters. Our application uses a
>> filter that logs the (first few characters of) post parameters. This
>> filter is installed as the first one in the filter chain, so nothing
>> else can interfere with it. For requests originating from pages which
>> logically can not produce such an empty post request, the log clearly
>> shows there are no parameters.
>>
>> The problem is often fairly random, although I have been able to
>> consistently reproduce it on one occasion. Using a proxy server to
>> monitor what my browser was sending, I clearly saw in the raw HTTP
>> headers that parameters where being send, yet they weren't received in
>> Tomcat. I also enabled TCP/IP packet logging at the server for a while.
>> For requests that appeared with empty parameters in Tomcat, the tcp/ip
>> log showed the parameters did arrive at the server.
>>
>> Next to that I enabled debug logging in the AJP connector, and again the
>> POST parameters were in the HTTP request but not present when the
>> mentioned filter logged the request in Tomcat.
>>
>> I did notice though that the overwhelming majority of the "empty post"
>> requests concerned Faces requests (we're using MyFaces 1.1.4). We store
>> state on client, so typical Faces HTTP post requests are at least 22KB
>> in size. Nevertheless, thousands of requests from the same pages from
>> all kinds of different browsers arrive with the post parameters intact.
>>
>> I'm at a loss here how to proceed. Naturally I could change JSF to keep
>> state on server, but because of the way some custom components work
>> that's currently not an option. It would also not really solve the
>> underlying problem of course.
>>
>> Any help would be greatly appreciated
>>
>>
>> Kind regards,
>> Arjan Tijms
>>
>> --
>> It's a cult. If you've coded for any length of time, you've run across
>> someone from this warped brotherhood. Their creed: if you can write
>> complicated code, you must be good.
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> --
> /bugslayer
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by thebugslayer <th...@gmail.com>.
I would suggest a TCP sniff tool like one found from axis or grinder
to peek at your http track to be sure.
On 8/24/07, M4N - Arjan Tijms <ar...@mbuyu.nl> wrote:
> Hi,
>
> We're hosting a fairly high traffic web application based on Tomcat.
> It's running on Debian-Etch, JDK 5.0U10 and Tomcat 5.5.20. We're using
> Apache as a front-end with the AJP connector.
>
> The problem I'm encountering is that for a percentage of the POST
> requests, Tomcat seems to loose all parameters. Our application uses a
> filter that logs the (first few characters of) post parameters. This
> filter is installed as the first one in the filter chain, so nothing
> else can interfere with it. For requests originating from pages which
> logically can not produce such an empty post request, the log clearly
> shows there are no parameters.
>
> The problem is often fairly random, although I have been able to
> consistently reproduce it on one occasion. Using a proxy server to
> monitor what my browser was sending, I clearly saw in the raw HTTP
> headers that parameters where being send, yet they weren't received in
> Tomcat. I also enabled TCP/IP packet logging at the server for a while.
> For requests that appeared with empty parameters in Tomcat, the tcp/ip
> log showed the parameters did arrive at the server.
>
> Next to that I enabled debug logging in the AJP connector, and again the
> POST parameters were in the HTTP request but not present when the
> mentioned filter logged the request in Tomcat.
>
> I did notice though that the overwhelming majority of the "empty post"
> requests concerned Faces requests (we're using MyFaces 1.1.4). We store
> state on client, so typical Faces HTTP post requests are at least 22KB
> in size. Nevertheless, thousands of requests from the same pages from
> all kinds of different browsers arrive with the post parameters intact.
>
> I'm at a loss here how to proceed. Naturally I could change JSF to keep
> state on server, but because of the way some custom components work
> that's currently not an option. It would also not really solve the
> underlying problem of course.
>
> Any help would be greatly appreciated
>
>
> Kind regards,
> Arjan Tijms
>
> --
> It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
/bugslayer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat looses POST parameters
Posted by M4N - Arjan Tijms <ar...@mbuyu.nl>.
Hi,
M4N - Arjan Tijms wrote:
> The problem I'm encountering is that for a percentage of the POST
> requests, Tomcat seems to loose all parameters. Our application uses a
> filter that logs the (first few characters of) post parameters.
To follow up on this issue, I think that I have probably found the cause
of this issue. In the AJP/1.3 connector configuration in server.xml, the
connectionTimeout had been set to a very low value (200). In the
catalina.[date].log this resulted in entries like:
Aug 29, 2007 4:27:21 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:23 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:25 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:26 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Except for message "31", there were also entries for Unknown message 8,
1, 19, 20, 22, 0, 29, 11 and 15, although 31 was the most common. I
missed these messages earlier (which is stupid of me, I know). I
compared the time stamps of these messages with those of the "empty
posts" in the other log file and found out they matched exactly or
almost exactly.
Looking up the code of HandlerRequest it appears to switch on a byte,
defined in org.apache.jk.common.AjpConstants. It actually switches on a
subset of these. The default action is to print the Unknown message line
and continue, which happens for the numbers I mentioned above.
Perhaps the connector is closing the connection early, but tomcat
somehow isn't signalled about that event and switches on a random byte
from the message the AJP connector was sending. Anyway, the result is
that the post request continues to be processed, but with missing
request parameters.
Setting the timeout value too low is of course our fault, but perhaps it
would be better if Tomcat could just abort the request and throw some
exception?
Kind regards,
Arjan Tijms
--
It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org