Hi.

Why are you sure that both the examples you are providing are POST requests ? (I am not saying they are not, but the "request method" does not appear in the logs below, nor does the full URL).

Also, referring to this
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13
the combination shown below in your log :

content-type:application/x-www-form-urlencoded; charset=UTF-8

does not seem to make sense.
The document above specifies : "Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set."

In other words, either the encoding is "application/x-www-form-urlencoded", and the parameters should be restricted to US-ASCII, or else the encoding should be "multipart/form-data".

So basically, it seems that whatever Ajax library you are using, is issuing HTTP requests that violate the official specs.

The problem as I see it, is that in such circumstances, the behaviour of whatever server module is processing these requests, becomes unpredictable, specially if they do follow the specifications.

André


Taylan Develioglu wrote:
- Apologies, I pressed send too soon.

The tomcat version I'm using is 6.0.18 w/ apr 1.3.3

Sun jdk 6u12 on debian 4.0.

following is the connector defined:

   <Connector port="80"                    p
protocol="org.apache.coyote.http11.Http11AprProtocol"
               keepAliveTimeout="10000" maxKeepAliveRequests="-1"
               enableLookups="false" redirectPort="443"
maxThreads="2000"/>


Thank you

--------

Hi,

I'm having an issue where the payload from http POST requests is lost.
This happens when using the APR connector, although sometimes it happens
with NIO too (but much less frequently).

Http headers are there, but the actual payload is missing (or at least
isn't reaching our application, but we don't think that's the issue)

The requests are polls to check for new events that have arrived and are
made by a javascript application (ajax).

example of a request where the payload is missing:

HTTP Request:
Session ID: A8F08DF4A71C7F6356DF10185D33195B
Path:/dispatch
Query String:null
HTTP Headers:
content-type:application/x-www-form-urlencoded; charset=UTF-8
accept-language:nl-be
referer:http://****
accept:text/javascript, text/html, application/xml, text/xml, */*
ua-cpu:x86
accept-encoding:gzip, deflate
user-agent:Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
host:*****
content-length:77
connection:Keep-Alive
cache-control:no-cache
cookie:mwc=0001236073658.353048.5; language=en-GB; Emessenger=msn;
network=MSN; msn_uname=*...@hotmail.com; eBuddyOberon.com=-;
tarid=1%3A0%3B2%3A99; JSESSIONID=A8F08DF4A71C7F6356DF10185D33195B;
__utma=1.1241670603699218000.1236073710.1236073710.1236073710.1;
__utmc=1;
__utmz=1.1236073710.1.1.utmcsr=ebuddy.com|utmccn=(referral)|utmcmd=referral|utmcct=/
HTTP Parameters:

The content-length is set by the browser, but the payload's gone (it
should be logged after HTTP Parameters:)

Normally the application logs data from the payload after the 'HTTP
Parameters' bit like this:

HTTP Request:
Session ID: A8F08DF4A71C7F6356DF10185D33195B
Path:/dispatch
Query String:null
HTTP Headers:
content-type:application/x-www-form-urlencoded; charset=UTF-8
accept-language:nl-be
referer:http://****
accept:text/javascript, text/html, application/xml, text/xml, */*
ua-cpu:x86
accept-encoding:gzip, deflate
user-agent:Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
host:****
content-length:77
connection:Keep-Alive
cache-control:no-cache
cookie:mwc=0001236073658.353048.5; language=en-GB; Emessenger=msn;
network=MSN; msn_uname=*...@hotmail.com; eBuddyOberon.com=-;
tarid=1%3A0%3B2%3A99; JSESSIONID=
A8F08DF4A71C7F6356DF10185D33195B;
__utma=1.1241670603699218000.1236073710.1236073710.1236073710.1;
__utmc=1; __utmz=1.1236073710.1.1.utmcsr=ebuddy.com|utmccn=(referr
al)|utmcmd=referral|utmcct=/
HTTP Parameters:
e_max:100
e_format:short
e_timeout:2000
e_action:poll
_:
e_time:1236077940847

These requests are not redirects btw.

Are there any known issues with the apr connector that can cause
something like this ? Could it be socket buffer related?

Any pointers or ideas what could be causing this would be welcome.



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

Reply via email to