Aspose.Words.Document.Save() to a HttpResponse does not encode the filename properly.
Usualy this is seems not to be much of a problem, as a) most filenames use us-ascii characters anyway, and b) most browsers are relatively robust handling invalid encoded stuff… Still, it is invalid according to the specs.
Suggestion: use the System.Net.Mime.ContentDisposition object to handle encoding
HTTP/1.1 200 OK
[uninteresting headers deleted]
content-disposition: inline; filename=test.mht
Now, if I save it using e.g. a norwegian file name “Hær.mht” (after the H is the a and e glued together), this is the file name sent over the wire:
content-disposition: inline; filename=H…r.mht
This is obviously not correct.
The remedy is in the Save() procedure not to just put the file name to a content-disposition header, but encode it. The encoding routines are present in the Microsoft class mentioned in the orignal post.
Thanks for your reply. Unfortunately, UrlEncoding is NOT the correct encoding for the filename in content-disposition. See http://tools.ietf.org/html/rfc2184, section 4.
I thought that the .Net ContentDisposition class was smart enough to handle this, but I’ve done some more testing and it appears that it is not.
I’ll find a way around this, but it remains an invalid header that Aspose sends out.
thanks for the link. The problem is much more complex, as there should be a * at the end of the filename parameter, indicating that the remainder is an encoded word(see RFC 2231).
What should be sent over the wire is something like this:
Thank you for additional information. I logged this request in our defect database as issue #7166. I will notify you as soon as it is fixed.
As a workaround, you can use the following code:
MemoryStream stream = new MemoryStream();
doc.Save(stream, SaveFormat.Pdf);
byte[] bytes = stream.GetBuffer();
Response.Clear();
//Specify the document type.
Response.ContentType = "**application/pdf**";
//Other options:
// Response.ContentType = "application/msword"
//Response.ContentType = "text/plain"
//Response.ContentType = "text/html"
//Specify how the document is sent to the browser.
Response.AddHeader("content-disposition", "attachment; filename=test.doc");
//Another option could be:
//Response.AddHeader "content-disposition","inline; filename=MyDocument.doc";
//Get data bytes from the stream and send it to the response.
Response.BinaryWrite(bytes);
Response.End();
I looked into the problem and it appears that Internet Explorer (I tested on IE6) does not support encoded words. I was not able to get it to display a file name properly. I used your example literally and IE was just returning the name of the aspx page + my extension instead of the document file name.
Also, if we were to implement this, we would refrain from using 8859- character sets because a filename can contain any Unicode characters. We would have to use UTF-8 or UTF-7 (which seems to be not recommended by the encoded word RFC).
The code that Alexey posted you earlier can be used as a workaround, it is essentially the way we do it in our Save method. By implementing writing to the browser yourself you can obtain complete control over the headers sent to the browser.
All this suggests me we should not bother changing anything in Aspose.Words at this stage.
The problem is that “the other browser” does a much better job in following standards than IE
Notice the little * directly after “filename”. This indicates that what follows is an encoded word. IE does not support this, FireFox and Safari (seem to) do. In stead, IE does support something that seems to be an url encoding (e.g. a space becomes %20), which FF does also support. But that does not solve all encoding woes. The word-encoding mechanism does, if used properly.
It can be done right, but need to support the different browsers in a different way. Tomorrow I’ll write up some code to give you a sample implementation that works both on IE and FF.
Ok I’ve done it the way it is described in the CodeProject article. Encode using UTF-8 and then hex escape. This works on IE. Most likely works on FireFox too.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.