Ok. Found the archives for source. Now all I've got to do is figure out how to get Eclipse to look at the source when I'm running Tomcat remotely. I'll review that page you sent the link to.
Richard > On Feb 9, 2015, at 10:14 AM, RICHARD DOUST <rdo...@me.com> wrote: > > We are running 7.0.57. I have not tried to debug yet, but am willing to give > it a try. I have gone to the apache site to download the source for that > version but can only find 7.0.59. If you can tell me how to get the source > for 7.0.57, I'll take it down, otherwise, I'll update the executable and use > the source for 7.0.59. > > I will try removing the CORS filter from the deployment and see if that > changes the behavior. I'll update this thread when I know the results. > > Thanks for your input. > > Richard > >> On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko <knst.koli...@gmail.com> >> wrote: >> >> 2015-02-06 23:30 GMT+03:00 RICHARD DOUST <rdo...@me.com >> <mailto:rdo...@me.com>>: >>> Hi, >>> >>> I've got an application that ran well with Tomcat 6.0, but is causing me >>> problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing >>> requests to the isapi_redirect (1.2.40) filter which is configured to send >>> some urls on to ajp13, then to port 8009 were Tomcat is listening), all >>> running on Windows Server 2003. >>> >>> I know the isapi filter is working because I've configured mappings to the >>> Tomcat docs and manager web apps and can get to them without any problems >>> (via IIS). >>> >>> I have a servlet deployed to Tomcat that I'm POSTing to via an >>> XMLHttpRequest in a browser. For the life of me, I cannot get it to respond >>> to me with anything but a 403 and I can't figure out why. It is not a >>> cross-domain request, so a CORS Filter (which is installed in support of a >>> rewrite of the application which is underway) can't be having any effect. I >>> have added an init-param to the servlet definition in the web.xml to make >>> sure that it's not an issue having to do with the fact that it's a POST: >>> >>> <servlet> >>> , >>> . >>> . >>> <init-param> >>> <param-name>readonly</param-name> >>> <param-value>false</param-value> >>> </init-param> >>> </servlet> >>> >>> >>> In the isapi_redirect.log I can see that the request is being passed to the >>> ajp13 connector. The request is well formed. Everything is as it should be. >>> The war file is configured as it was configured with Tomcat 6.0, in terms >>> of its deployment descriptor with the above minor difference. Here is an >>> excerpt from the isapi_redirect log with the request itself preceding >>> what's shown here: >>> >>> 00 00 00 - ManagerRqst>.... (Tail end of request XML) >>> [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 >>> pos=0 len=38 max=8192 >>> [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0000 04 01 93 00 >>> 09 46 6F 72 62 69 64 64 65 6E 00 00 - .....Forbidden.. >>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0010 02 A0 01 00 >>> 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .....text/plain. >>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020 A0 03 00 01 >>> 30 00 00 00 00 00 00 00 00 00 00 00 - ....0........... >>> [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] >>> ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 >>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] >>> ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 >>> [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] >>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = >>> [text/plain] >>> [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] >>> ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = >>> [0] >>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] >>> start_response::jk_isapi_plugin.c (1025): Starting response for URI >>> '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1) >>> [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] >>> start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive >>> [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 >>> pos=0 len=2 max=8192 >>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] >>> ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0000 05 01 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 - ................ >>> [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] >>> ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK >>> [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] >>> HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK >>> [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] >>> ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with >>> socket 2300 >>> [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] >>> ajp_done::jk_ajp_common.c (3144): recycling connection pool for worker >>> ajp13 and socket 2300 >>> >>> I have a breakpoint set in the servlet's doPost method. It gets hit if I >>> use the rewrite which bypasses IIS and goes direct to port 8080 to hit >>> Tomcat directly. It does not get hit when the request is sent via IIS. I >>> have no insight into what or where the problem might be. Somewhere between >>> ajp13 and Tomcat. >>> >>> The application works without a problem if I hit it from a browser running >>> on the same computer as is running IIS and Tomcat. It doesn't work if I hit >>> it from a client from outside. >>> >>> I've been banging my head against this for 2 days. Any help would be >>> appreciated. >> >> 1. You are not saying what exact version of Tomcat 7.0.x you are using. >> >> 2. If you are debugging it, put a breakpoint on >> org.apache.catalina.connector.Response.sendError() and look what calls >> the sendError() method. >> >> As a reminder (maybe you already know that), >> http://wiki.apache.org/tomcat/FAQ/Developing#Debugging >> <http://wiki.apache.org/tomcat/FAQ/Developing#Debugging> >> >> 3. There currently is another thread about CORS filter and 403 errors >> ("Sporadic HTTP 403 returned by Tomcat when this should not happen >> ever. How to find out why this happens?") >> >> If you sure that CORS filter does not matter, then try without it. >> >> The filter itself is relatively new. Code review, debugging and >> testing is welcome. >> >> >> Best regards, >> Konstantin Kolinko >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> <mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> <mailto:users-h...@tomcat.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
