Hi Andre, We are sure because we wrote the ajax application that sends the requests. Or in other words, they should be . (/dispatch does not get called any other way by the app).
That's a very interesting point there you make regarding the content-type. I am not sure why we are using it that way because it's a normal post that's being done. Could it be that this is causing apr in some instances to reject the content? Possibly NIO allowing some cases where APR does not. Very interesting lead there, thanks André Warnier wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
