The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.
Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION): Multiple Content-Disposition headers received. This is disallowed to protect against HTTP response splitting attacks.
using a url like
http://host:port/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=...
then the issue may be that there is a Content-Disposition header being sent back from BlobServer/Satellite, which is setting a filename for the download, and the filename has a comma in it. e.g.
Content-Disposition: attachment; filename=image,5.jpg
Content-Type: image/jpeg
Chrome doesn't like the presence of the comma, although it is not strictly speaking a bug (See http://code.google.com/p/chromium/issues/detail?id=103618). Chrome is interpreting the HTTP RFC to the letter by expecting the filename to be double quote escaped due to the presence of the comma, like so:
Content-Disposition: attachment; filename="image,5.jpg"
Content-Type: image/jpeg
The tags satellite:blob, render:satelliteblob or render:getbloburl are where Content-Disposition header is set, in the template code, so adjust this to ensure that the filename value is double quoted, or encode it another way. This solution by S. James is to use URLEncoder:
<satellite:argument name="blobheadervalue1" value='<%="inline; filename=" + URLEncoder.encode( ics.GetVar("BlobFileName"),"UTF-8") %>'/>
Unfortunately browsers vary in the way they interpret Content-Disposition header, WebCenter Sites does not get involved with attempting to negotiate the best value for a browser, it will just set what the developer chooses to set, so it is a developer challenge to find the best Content-Disposition values to use. A good reference for what works on different browsers is http://greenbytes.de/tech/tc2231/.
