It's all about the answers!

Ask a question

Any pointer where to look for the cause of "NetworkError: 400 Bad Request - https://..." when creating a new WI of a specific type ?

long TRUONG (3654121147) | asked Oct 02 '14, 10:40 p.m.
 After upgrade from RTC 4.0.3 to 4.0.6: Symptoms as described in Jazz Forum question 163394; when create a new WI, or open an existing one, of type Story_xxxx, using WF ScopeItem, on webUI only:
  • Dropdowns no longer expand into enumerations
  • Most fields got a red circled Xmark
Submitted  [PMR 55525,49R,000] , monitored browsers with FireBug, HTTPwatch, and Chrome Inspect element as advised: All reports pointed to a "NetworkError: 400 Bad Request" evry time a new WI (of the specific type with the specific WF) is created or an existing one is opened.

Have since created a brand new PA, with the process template cloned from the troublesome PA, the issues can be produced at will with creation of new WI of ther particular type.

SWAT spotted miss-configured non-Attribute-Based boolean fields, they have since been fixed. but the issues and error 400 persisted. 

On the brand new PA, we can also reproduce the same error when just switch to the PA on webUI. None of the issues are experienced on the Eclipse-based clients. Any idea where we and SWAT should be looking. Anything like the JSESSIONID issue posted on Jazz Forum question 161232 (after upgrade from 4.0.5 to 4.0.7).

Error 400, via Firebug, when switch to the PA on webUI:

"NetworkError: 400 Bad Request - https://<RTCserver:port>/ccm/service/"



[object Object]

_6()?includ...e=en-us (line 2485)

_6()?includ...e=en-us (line 6183)

_13()?includ...e=en-us (line 6198)

Error 400, via Firebug, when a new WI is created on webUI:

"NetworkError: 400 Bad Request - https://<RTCserver:port>/ccm/service/"



[object Object]

_6()?includ...e=en-us (line 2485)

_6()?includ...e=en-us (line 6183)

_13()?includ...e=en-us (line 6198)

long TRUONG commented Oct 02 '14, 11:49 p.m.
Wonder if this could jog your thinking to help us: Both the webUI and the Eclipse-based client are using exactly the same URL to open a particular WI:
Why it works on the client but not on webUI? 
What's the difference between the two when sending in the URL and when receiving responses from the server?
Is it in the credential packaging? 
Are they sending different infos or different containers of same contents to the server?
Bad request: Must be something from the webUI which is not recognized by the server!
What has changed from 4.0.3 to 4.0.6 in sending in infos to the server or in server receiving infos?
Could it be some wrong got right on webUI 4.0.6 and not yet on client, which still tolerates old bad habits?

long TRUONG commented Oct 17 '14, 2:29 p.m.

 The issues described in Jazz Forum question 163394 are the direct results/symptoms of  Batching of all fetch value set calls (Task 281676),  introduced in 4.0.5, which  is making a single HTTP GET request longer than the default 8192 Tomcat header size:  Defect 334472 with APAR PI27659 created but not yet published. Workaround in right answer.

Accepted answer

permanent link
Donald Nong (14.5k614) | answered Oct 03 '14, 2:17 a.m.
edited Oct 03 '14, 2:21 a.m.
I cannot answer all your questions but I have found a possible cause, and a solution - the offending URI is too long for the application server (Tomcat in my case) to accept. Changing a parameter in Tomcat resolves the issue in my case.
The offending URI is 11000+ in length, way more than the default header size (8192) configured for the bundled Tomcat server. To overcome this, change the parameter and restart Tomcat.
<Connector port="9443"
If this approach also works for you, you can investigate further down the track to get all the other answers.

long TRUONG selected this answer as the correct answer

long TRUONG commented Oct 03 '14, 10:43 a.m.

Thx Don,

This is very much in line with one of the admin (on the project team)'s suspicion of too many attribs/fields on the form. We had created a new PA just to eventually test reducing the number of fields on the form as we don't know enough about Tomcat. You have given us a much less onerous way to achieve the same goal.

long TRUONG commented Oct 07 '14, 12:20 a.m.

 We have passed the testing of Tomcat maxHttpHeaderSize to SWAT to avoid RFC (yes, even on TEST env). However we traced the offending (11046 chars) URI to a tab (Tracking) on the form and have tried to remove enough sections from the tab to reduce the URI to 8066 then 7658 respectively, to circumvent the RFC process in testing your suggestion. Though the URI is less than 8192, it still did not work. Removing this tab entirely would work, as SWAT first recommended. However this solution is hard to swallow, as it requires reconstructing the tab by re-adding the sections back in while leaving several sections with miss-configured boolean fields, which can easily be re-configured, out, 

Donald Nong commented Oct 07 '14, 1:59 a.m.

I am surprised to hear that a URI which is 7658 in length still does not work. Are you certain that the issue is still the same, as in, Tomcat rejects the request? With the ccm.log file, you should be able to see whether the request has been passed on to the CCM application. If it is now CCM rejecting the request, that's another story.

long TRUONG commented Oct 07 '14, 7:08 p.m.

@Don: Yes, it is the same 400 Bad Request from Tomcat, with similar infos in the URI, minus fields (or attributes ?)   removed from the tab. There are exactly the same number of same URIs/lines up to last one as on the Firebug report for the case with the tab removed, except for the additional line with the error. There seem to be something with this tab that Tomcat does not like.,,, This was never posted since this morning ... Now have better new in the following post. 

long TRUONG commented Oct 07 '14, 7:25 p.m.

SWAT has come back and confirmed that increasing  Tomcat maxHttpHeaderSize  worked. So we are going to submit RFC to start on TEST then move to PRD. Still puzzled as Tomcat maxHttpHeaderSize   is explicitly set to 8192 on both 4.0.3 and 4.0.6, yet we did not run into the issue on 4.0.3.

long TRUONG commented Oct 07 '14, 7:30 p.m.

 BTW Do we set to higher value all 3 instances of maxHttpHeaderSize found in:

Line 87:     <Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="yyyy" redirectPort="xxx"/>
Line 101:     <Connector port="xxx" maxHttpHeaderSize="8192"
Line 108:     <Connector SSLEnabled="true" URIEncoding="UTF-8" acceptCount="100" algorithm="${jazz.connector.algorithm}" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keystoreFile="ibm-team-ssl.keystore" keystorePass="ibm-team" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" .... ocol="${jazz.connector.sslProtocol}"/>

Donald Nong commented Oct 07 '14, 7:45 p.m.

In my environment, I only need to change one place - line 108 in your case, where the connector is for port 9443. The connector for 9080 by default is redirected to 9443 and I don't see the maxHttpHeaderSize parameter would have any effect. Interestingly I only see the parameter maxHttpHeaderSize once in my default Tomcat configuration. Also check whether some connectors are actually commented out (wrapped by <!-- -->)
The default Tomcat configuration in CLM only defines three ports - 9080 (for HTTP, which redirects to 9443), 9443 (for HTTPS) and 9009 (for AJP, think of a gateway to send commands to Tomcat).

long TRUONG commented Oct 07 '14, 8:15 p.m.

Thx Don: That was quick !

100 <!--
101  commented out < ...
105 ....   />
106 -->

But 87 and 108 are active. 87 does redirect 9080 to our HTTPS port (not 9443 in our case).

long TRUONG commented Oct 09 '14, 4:46 p.m.

We have confirmed this workaround on our TEST env. However SWAT still investigate for the root cause, as Tomcat is configured same on 4.0.3 and 4.0.6 yet the one tab with too many fields/attibutes (11046 chars > 8192 configured header) worked on 4.0.3 and get caught by 4.0.6. Also our attempts to reduce sections of the offending tab to bring the request URI to less than 8192 did not corroborate   

long TRUONG commented Oct 17 '14, 2:32 p.m.

@Don: You may be interested in looking at  Defect 334472 (with APAR PI27659 created but not yet published).

Donald Nong commented Oct 19 '14, 7:53 p.m.

Thanks for the link. It's a nice read and the solution of using POST to get all the attributes is what I have anticipated. Now I know why the problem did not appear with CLM 4.0.3.

showing 5 of 11 show 6 more comments

One other answer

permanent link
Eric Jodet (6.3k5111120) | answered Oct 03 '14, 2:19 a.m.
I guess your issue might be investigated in the PMR (since this looks like a server error)
However - I could imagine that some presentation / attributes were deprecated in 4.0.6.
Opening your PA in the Eclipse Client,
and looking at all types attributes / presentation should show you some warning.
On the XML source tab of the PA - possibly you'll get some validation errors.


long TRUONG commented Oct 03 '14, 10:53 a.m.

Thx Eric,

Our PMR for this is still with SWAT, who had spotted our several miss-configured non-Attrib-based Boolean fields which we fixed them all to attributes already in place and meant for those fields. We also found and fixed one field with deprecated kind MultiSelect & another with no longer in existence kind Description. However those miss-configured fields were just ignored and not on the request URI, hence never showed up on webUI or client's form: the issue with error 400 persists over their fix.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.