HTTP 400 error and URL contain sessionid nameJsession and Session expire page

[brahmanandam konikineni]

Currently the session id is 16 bit in tomcat .We need to make it 128 bit encrypted value.

Analysis :-


We have faced two issues in testing server where users were getting kicked out of the application when user search for the job and also encountering 400 Bad request. I have made quite few changes in server level. I have modified context.xml (added one line i.e <Manager sessionIdLength="128" /> ) from D:\Program Files\Apache\Tomcat_A\conf in All server level).


When I tried to hit application home page through application portnumber I am able to access the application successfully.The following problems are faced in QA through IIS only

When the user clicks the link it shows the HTTP 400 error and URL contain sessionid nameJsession=1FE3DDF28484E473A32E0A09E823D9D240F563A675C5BCE8F64F6DEE9163CC7DF7002BC6D339706B1AA72E1D41549A52E1245A2FD720BEB11A1B6E3DE43CC3651E3C3AF4F16CA4A32E72C85B654C1BFFF67D836C0634ED2E31CE1B32F0193C8D52F82F431DCB4133CFA81F896665B74EE5E6831727782130187FF8B7B43530E0.tomcatA
This happens first two times when we try to login and found in the view source of the page that "jessionid" is created. Third time we are able to login to application.


When the user logged into application,goes to Administration link and clicks the Scheduler History link after searches for any of the Job and runs it, user is getting kicked out of the application. It shows Session expire page.


Normal request process in environment, When ever user login to application it goes to tomcat B,C and E servers and one request goes to Tomcat A out of 10 requests. Now when the user goes to Administration link and clicks on the Scheduler History link and search for any job it goes to tomcat A server and it shows Session expire page.


In HTTP logs, It is showing the following error
443 HTTP/0.0 Unparsed - 400 - BadRequest -
443 HTTP/0.0 Unparsed - 400 - BadRequest -
443 HTTP/1.1POST /ezx/login.do;jsessionid=31ACBCD2B8391CDD615CB26BDD1D249E7B8CA79F0A4E6C71E92B7C508755E5C9B14561CB71492595B4CD149B085813D28834E2F806BF7376F2C76EB4A544D52921844D93E2AB0FADABA569AFE3A4088105378FC27C901C6F234E45AE0D6D3EAFFFC524EDF9578CE25A5E321E3E4B7B5118E1C0D8C35156318C8E1B49A9185371.tomcatC 400 - URL -443 HTTP/1.1 POST /ezx/login.do;jsessionid=31ACBCD2B8391CDD615CB26BDD1D249E7B8CA79F0A4E6C71E92B7C508755E5C9B14561CB71492595B4CD149B085813D28834E2F806BF7376F2C76EB4A544D52921844D93E2AB0FADABA569AFE3A4088105378FC27C901C6F234E45AE0D6D3EAFFFC524EDF9578CE25A5E321E3E4B7B5118E1C0D8C35156318C8E1B49A9185371.tomcatC 400 - URL -




Solution Approach :-


Tested following things for solve this problem:

1. I have created DWORD values under the following registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters


UrlSegmentMaxLength(By default 512) increased to 1024 and more
MaxFieldLength and MaxRequestBytes increased as per requirement.

2. Increased the session time out in configuration file and added some more distributable options in context .xml file.

3. I verified ISAPI redirector reads configuration from the following registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0

key value= strip_session
uses = A string value representing a boolean. If it is set to true, URL session suffixes of the form ";jsessionid=..." get stripped of URLs, even if the are served locally by the web server.

After these changes issues still not get resolved. I am not sure if this is related IIS issue or some other issue. Can anyone please help me in this issue?

[Tim Holloway]

I think that your main issue is that you've got a home-grown security system. Not only are DIY security managers infamously - almost universally - insecure, they are frequently designed by people who liked to show how "clever" they were by doing cute things with server internals that were never all that stable to begin with.

You imply that you are fronting Tomcat with IIS, which, unfortunately takes it completely out of the realm that I can advise on. Or at least advise on for free. Occasionally I have to earn my keep, and resolving the really tough problems are what do it.

About the only help I can give under the circumstances is to note that jsessionid is a fallback mechanism that Tomcat uses to propagate the session handle between client and server when cookies are not available. The length of your sample jsessionids makes me suspect that your "clever" security people have been mucking around with it without a proper understanding of its use, since it should be a lot shorter than that.