CA Service Desk Manager (CA SDM) Exports fail only through Microsoft Internet Explorer

Document ID : KB000030044
Last Modified Date : 14/02/2018
Show Technical Document Details

This problem was reported by a single customer, but may show up again for other customers if an underscore is used in the URL for CA SDM web interface. This problem was unique to when there was an underscore in the URL.  The solution is to not use an underscore in a URL.

For a full explanation, continue reading: 

  • A fiddler trace of Internet Explorer was used, comparing the output against Fiddler output when Google Chrome was used. Fiddler is a free web debugging proxy for any web browser.
  • We had looked into the fiddler traces gathered from the customer’s working (Chrome) and failing (IE) scenarios. The complete observation is from the developer point of view. This may be helpful for troubleshooting similar issues.
  • It was observed that following request was being sent to the webserver to download the file:

http://<IP ADDRESS>:8080/CAisd/pdmweb.exe?SID=1473951170+FID=4027+OP=LINK_WITH_BOPSID+KEEP_ROLE=1+CALLBACK=export_cb('cr','%25bopsid') 

  • The webserver responds with the below response:


Note: The above function export_cb JavaScript is defined in http://<IP ADDRESS>:8080/CAisd/scripts/std_list.js      The function in that java scrtip is: export_cb(factory, bopsid)

  • This is the function responsible for sending below request to another webserver which has the download file logic.



  • The webserver CA_SDM sends the below response.


<script language="javascript">"http://CA_SDM:8080/CAisd/html/export_file.html?url=http://CA_SDM:8080/CAisd/PDMExport&status","","directories=no,location=no,top=300px,left=300px,menubar=no,status=no,height=300,width=450");</script></body></html>

http://CA_SDM:8080/CAisd/html/export_file.html as the logic to download the file which is taken care by SubmitExportForm() JavaScript function.

 // Copyright (c) 2005 CA.  All rights reserved.

function SubmitExportForm()


var qsParm = new Array();

qsParm['url'] = null;      

qsParm['request_id'] = null;      

var query =;

var parms = query.split('&');

for (var i=0; i<parms.length; i++) {

var pos = parms[i].indexOf('=');

if (pos > 0) {

var key = parms[i].substring(0,pos);

var val = parms[i].substring(pos+1);

qsParm[key] = val;



var url = qsParm['url']; 

var request_id = qsParm['request_id']; 

var pattern = /javascript/gi

var javascript_check = url.match(pattern);

pattern = /%3C/gi

var left_brace_hex_check = url.match(pattern);

pattern = /%3E/gi

var right_brace_hex_check = url.match(pattern);

var left_brace_check = url.match("<");

var right_brace_check = url.match(">");

if(javascript_check != null ||

left_brace_hex_check != null ||

right_brace_hex_check != null ||

left_brace_check != null ||

right_brace_check != null )


alert("Security warning: XSS manipulation exiting...");

url = "";




alert("Error during retrieval of request handle, see logs for details.");



var status_url=url+"?status="+request_id;


// NOTE: This is the line of code which does the request to http://CA_SDM:8080/CAisd/PDMExport?status=null



  • The above request which gets the response and been handled by SubmitExportForm() JavaScript function should send the subsequent request to



  • Until this point of the above request, the behavior is same in both IE and Chrome.
  • In IE the above request doesn’t get the response whose “Content-Length: 0”, whereas Chrome responds with “Content-Length: 166” whose response is as below.


<script language="javascript">parent.opener.location.href = "http://CA_SDM:8080/CAisd/PDMExport?send_data=";parent.close();</script></body></html>


  • Actual file download should happen once the request http://CA_SDM:8080/CAisd/PDMExport?send_data is sent from the browser.
  • As IE does not get this response, it is not even sending the request to http://CA_SDM:8080/CAisd/PDMExport?send_data due to which IE is not able to download the file. But Chrome gets this and sends the subsequent request. Hence file can be downloaded through Chrome.
  • Further debugging this issue to find out the actual reason for the failure in IE. It is been observed that when the request is initially sent to the webserver

http://CA_SDM:8080/CAisd it sends the below response header to set the cookie in the first request itself.

Set-Cookie: JSESSIONID=7FA3FB86B70E8D01F8C99B84DDB14C03; Path=/CAisd/; HttpOnly

  • For any subsequent requests in Chrome, it makes use of the above cookie and we see the above cookie sent in the Chrome request headers and functionality works as expected.
  • Whereas we do not see the above cookie sent in IE and it is blank. This means that IE did not consider the above Set-Cookie response header due to which the failure is and cannot download the file as the cookie is missing.
  • Inspecting why the cookie is not considered in IE set by the http://CA_SDM:8080/ webserver, it was observed that the name of the webserver host contains the “_” character for which IE ignores as IE won’t set a cookie when the hostname/domain contains an underscore.
  •  Technically, an underscore (like this _ ) is not a valid DNS character, and while Windows will let you use an underscore when naming your machine, it warns you that doing so may cause problems. One such problem is that WinINET blocks attempts to set cookies on such domains. See
  •  Domains that use cookies must use only alphanumeric characters ("-" or ".") in the domain name and the server name. IE blocks cookies from a server if the server name contains other characters, such as an underscore character ("_").
  • More information about these cookie restrictions is discussed in the article question no.5