AW: AW: ISAPI Redicect - Request Entitiy too large
Yes, that´s it. We changed the size to 12k and everything works fine. It is a lot tricky, that the default value is not fitting in a default environment. Thanks to all for your help. BR Alex -Ursprüngliche Nachricht- Von: cjder...@gmail.com [mailto:cjder...@gmail.com] Im Auftrag von chris derham Gesendet: Mittwoch, 5. Oktober 2011 12:53 An: Tomcat Users List Betreff: Re: AW: ISAPI Redicect - Request Entitiy too large Alexander, If you are using authorisation header, then you are using SPNGEO. This header encodes the users group membership in the authorisation header. By default tomcat has an 8k maximum header, whilst users belonging to many groups can have an authorisation token that can swell to larger than this size. This explains why you see some people can login and others can't. Just change the maxHttpHeaderSize to something larger than the default 8k and you should be set. We used 32k Chris smime.p7s Description: S/MIME cryptographic signature
AW: ISAPI Redicect - Request Entitiy too large
Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008 port=80 auth=Negotiate user=DOMAIN\USERNAME uri=/jci/ [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3356): Service request headers=8 attributes=0 chunked=no content-length=0 available=0 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] HttpExtensionProc::jk_isapi_plugin.c (2228): got a worker for name worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0 after 0 retries [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error]
Re: AW: ISAPI Redicect - Request Entitiy too large
Alexander Diedler wrote: Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Ok, basically thanks. I just wanted to know if the NTLM authentication dialog could explain some extra-large headers. But in this case, apparently not, since the authentication dialog happens between the browser and IIS, and should not even be seen in Tomcat. (Apart from the final Authorization: header). One item in your above explanation does not fit : username and password cannot be. There is no way that the IIS authentication would produce a user password that you can pass on to Tomcat. Userid yes, password no. (But it does not matter for the current issue). Anyway, what about a difference between the workstations for which it happens, and the ones for which it does not ? any visible OS/browser difference ? Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008
Re: AW: ISAPI Redicect - Request Entitiy too large
Addendum : can you increase the log level of isapi_redirect on the IIS server, and try again ? it may show us a bit more about what is happening. André Warnier wrote: Alexander Diedler wrote: Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Ok, basically thanks. I just wanted to know if the NTLM authentication dialog could explain some extra-large headers. But in this case, apparently not, since the authentication dialog happens between the browser and IIS, and should not even be seen in Tomcat. (Apart from the final Authorization: header). One item in your above explanation does not fit : username and password cannot be. There is no way that the IIS authentication would produce a user password that you can pass on to Tomcat. Userid yes, password no. (But it does not matter for the current issue). Anyway, what about a difference between the workstations for which it happens, and the ones for which it does not ? any visible OS/browser difference ? Greetings Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 10:15 An: Tomcat Users List Betreff: Re: ISAPI Redicect - Request Entitiy too large Alexander Diedler wrote: Hello @ll, I have installed a new Windows 2008 R2 x64 Server with IIS7 and Tomcat 6.0.32 x64 Edition. We use SSO Authentication from IIS to the Tomcat. Which SSO mechanism ? Suddenly, we got on some clients, but not on every client (that´s stupid!) the following error: Request Entity Too large! which does look strange, considering that there is a Content-length: 0 header below. It looks a bit as if a HTTP *header* in the request was too large. Repeat question : can you be a bot more specific about the authentication mechanism used ? Also, if you can determine a difference, what is the difference between the clients where it happens, and the ones where it does not ? The HTTP method does not allow the data transmitted, or the data volume exceeds the capacity limit. Jakarata/ISAPI/isapi_redirector/1.2.32 () The isapi.log contains the following messages in debug mode: [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] find_match::jk_uri_worker_map.c (863): Found a wildchar match '/jci/*=worker1' [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540]
AW: AW: ISAPI Redicect - Request Entitiy too large
::jk_isapi_plugin.c (1978): check if [/jci/] points to the web-inf directory [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (1994): [/jci/] is a servlet url - should redirect to worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] HttpFilterProc::jk_isapi_plugin.c (2034): fowarding escaped URI [/jci/] [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] wc_maintain::jk_worker.c (339): Maintaining worker worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3022): Reading extension header HTTP_TOMCATWORKER00018000: worker1 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3023): Reading extension header HTTP_TOMCATWORKERIDX00018000: 3 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3024): Reading extension header HTTP_TOMCATURI00018000: /jci/ [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3025): Reading extension header HTTP_TOMCATQUERY00018000: (null) [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3085): Applying service extensions [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Connection : Keep-Alive [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Content-Length : 0 [Fri Sep 30 15:06:08.445 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept : */* [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Encoding : gzip, deflate [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Accept-Language : de-DE [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header Host : b0621s008 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3309): Forwarding request header User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3344): Service protocol=HTTP/1.1 method=GET host=fe80::3d83:4ce1:6ac:83dd%11 addr=fe80::3d83:4ce1:6ac:83dd%11 name=b0621s008 port=80 auth=Negotiate user=EUBATT\bamelas uri=/jci/ [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] init_ws_service::jk_isapi_plugin.c (3356): Service request headers=8 attributes=0 chunked=no content-length=0 available=0 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] HttpExtensionProc::jk_isapi_plugin.c (2228): got a worker for name worker1 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0 after 0 retries [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] ajp_marshal_into_msgb::jk_ajp_common.c (469): failed appending the header value [Fri Sep 30 15:06:08.460 2011] [3456:1540] [info] ajp_service::jk_ajp_common.c (2431): Creating AJP message failed, without recovery [Fri Sep 30 15:06:08.460 2011] [3456:1540] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 413 [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_reset_endpoint::jk_ajp_common.c (807): (worker1) resetting endpoint with socket -1 (socket shutdown) [Fri Sep 30 15:06:08.460 2011] [3456:1540] [debug] ajp_done::jk_ajp_common.c (3078): recycling connection pool slot=0 for worker worker1 -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 5. Oktober 2011 11:44 An: Tomcat Users List Betreff: Re: AW: ISAPI Redicect - Request Entitiy too large Addendum : can you increase the log level of isapi_redirect on the IIS server, and try again ? it may show us a bit more about what is happening. André Warnier wrote: Alexander Diedler wrote: Hello, We use the IIS integrated (Windows) domain authentication, which is passed to the Tomcat and then we check the given String with our user database in the app and if username and password match, the user was automatically logged in (SSO). Ok, basically thanks. I just wanted to know if the NTLM authentication dialog could explain some extra-large headers. But in this case, apparently not, since the authentication dialog happens between the browser and IIS, and should not even be seen in Tomcat. (Apart from the final Authorization: header). One item in your above explanation does not fit : username and password cannot be. There is no way that the IIS
Re: AW: ISAPI Redicect - Request Entitiy too large
Alexander, If you are using authorisation header, then you are using SPNGEO. This header encodes the users group membership in the authorisation header. By default tomcat has an 8k maximum header, whilst users belonging to many groups can have an authorisation token that can swell to larger than this size. This explains why you see some people can login and others can't. Just change the maxHttpHeaderSize to something larger than the default 8k and you should be set. We used 32k Chris
