• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:



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.

Thanks.
 
Saloon Keeper
Posts: 28430
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm unclear what security mechanisms you are using in Tomcat.

The built-in security mechanism works using URL patterns defined in the webapp's web.xml file. You could have problems here if an attempt was made to issue a request against a protected pattern and the URL security role(s) defined for that pattern didn't match any of the roles defined for that user. Or if the automatic login mechanism failed somehow.

One thing I'd look at is the transport security element of the web.xml file.
 
Anderson gave himself the promotion. So I gave myself this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic