HTMLLoader & Content-Disposition of type attachment

HTMLLoader in Adobe AIR 1.0 does not handle the HTTP
Content-Disposition response headers set to type 'attachment'. It
simply ignores this header. This is bad, because many sites on the
web rely on user-agents handling this header appropriately in order
to initiate a download of a file to an end-user's local disk.
An example is
Content-Disposition: attachment; filename="fname.ext"
This HTTP response header says to the user agent, 'Don't
render this response as HTML; instead write the response to a file
on the user's disk called fname.ext'.
When the Air HTMLLoader encounters an HTTP response with a
Content-Disposition similar to the example above, nothing is
re-rendered (which is the correct behavior), there is no way to
detect that the attachment Content-disposition header has been
served (bad), and there is no way to obtain the attachment itself
(worse).
The correct behavior for an HTTP client which receives an
HTTP response parameter of this type can be found in RFC 2616,
section 19.5.1. It is stated that "If this header is used in a
response with the application/octet-stream content-type, the
implied suggestion is that the user agent should not display the
response, but directly enter a ‘save response as...’
dialog". I suspect that Adobe hasn't had a chance to implement a
way for HTMLLoader to notify client code of this situation, or the
process for getting the HTTP response body.
Has anyone encountered a work-around? Does anyone know of
plans in place to correct this bug?

The problem is that the server script is treating the request as a request for a file to download, rather than as a typical HTTP request/response. You need to modify the server script so that it doesn't include the Content-Disposition header, there's not much you can do on the client side.

Similar Messages

Change content-disposition in email attachment

I am using apex_mail (in Apex 4.1) to send emails with an attachment.
v_mail_id := apex_mail.send(
         p_to => '[email protected]'
         ...etc...
apex_mail.add_attachment( p_mail_id    => v_mail_id
                         ,p_attachment => v_image
                         ,p_filename   => 'signature.jpg'
                         ,p_mime_type => 'image/jpeg');
Apex creates this as an attachment:
Content-Disposition: attachment;
I would like to change it to inline:
Content-Disposition: inline;
so I can reference it in my email body with <img src="cid:signature.jpg"/>. Well... I hope it is going to be shown inline anyway if I change Content-Disposition.
Currently (with Content-Disposition: attachment;) it works for Outlook, but, for instance, not in Gmail in the browser. Gmail shows the image separately as an attachment.
Is there a way to change the content-disposition with Apex?
I know it is possible to do it with utl_mail, but this is currently not installed in our databases. I need to involve our DBA to set this up, and I don't know if he is willing to do that.

Hi Joel,
I thought so. I will put this in the Apex feature request database.
Ino
BTW, for other people it might be interesting to know that there is another option I tried that doesn't work in many situations either. You can put this in the email body:
<img src="data:image/jpeg;base64,'||v_image_base64||'"/>
where v_image_base64 is the base64 encoded jpg image.
From my experiments the inline attachment with a cid reference seems to work best.

Inline type of Content-Disposition problem in IE

Hi,
In a project, we need post some information from applet to servlet. The servlet will send some files back. We like the files shown on browsers. So we set the header in servlet as
response.setHeader("Content-Disposition",
"inline;filename=\"" + fileName + "\"");
We use JSobject in applet to call form from a html file to post the information to servlet, target of the form is set as "_blank", which suppose will open a new browser and show the file. For example if the file is a word file, the IE will show the file inside browser.
However, if two files need to be shown, only the first file is shown, the other browser is blank, and when you kill the blank window, the other will turn to blank window too. We test other types of file, xls files have similar problem, the PDF files work OK. Two things can fix the problem, one is set the form method to ��get��, the other is changing the header from ��inline�� to ��attachment��. But we can't use any of them under the project requirement. Has anyone experienced such wield behavior and know the reason? Is this the bug of IE?
Thanks in advance!

Here are a little more about the file types.
The files we test have problems are msword or excel files, I think all MS office type files have the problem. Same problem even you mix them, for example one word file and one excel give you the same problem as two word files.
However there is no problem if I view several PDF files. If we mix the word file with pdf file. If the first file to view is PDF, then it works OK. Otherwise same problem.
The browser we are testing IE 6.0 with SP1.

("Content-Disposition", "attachment;filename=x") works in Netscape; not IE.

I'm sending an ASCII file back to the client using the following method:
private void sendFile(String fullFilePath, HttpServletResponse res) {
if(fullFilePath!=null) {
try {
res.setContentType("application/text/plain"); //this will be an unknown type
res.setHeader("Content-Disposition", "attachment;filename=" + fullFilePath);
FileInputStream fi = new FileInputStream(fullFilePath);
OutputStream out = res.getOutputStream();
while(true) {
int d = fi.read();
out.write(d);
if(fi.available()==0)
break;
fi.close();
out.close();
catch (Exception e) {
Logger.err.println("Error in TableQueryServlet.sendFile(): " + e,Log.ERROR);
This works great in Navigator. The filename that it defaults to in the Save file dialog box is the same one I set it to using the fullFilePath string - including the .txt extension. However, in IE it ignores my filename and assigns its own random filename. Any ideas how I can get this to work in IE?

It's not the greatest, but see the following...
MS knowledgebase # Q279667

Missing "Content-Disposition" and attachment's file name

We're testing OCFO 10.1.3.0.6 with MS Outlook 2003 and found some problems when message with attachments is received.
If the attachment's file name is encoded and the body part looks like:
Content-Type: application/msword; name="=?utf-8?B?encoded name?="
Content-Disposition: attachment; filename="=?utf-8?B?encoded name?="
everything is OK - the message is displayed as expected and the attachment's file name is decoded right.
But, if Content-Disposition field is missing, the attachment's file name is not decoded - it's displayed as "=?utf-8?B?encoded name?=" (the name is obviously taken from Content-Type's name parameter), we loose information about file's type and we can't open the attachment.
It seems that MS Outlook (without OCFO) is "smart" enough to decode Content-Type's name parameter as file name in the absence of Content-Disposition field. The same is true for Thunderbird.
Any ideas?

Actually the "name" parameter in Content-Type was declared depricated in RFC 1521 in september 1993, (now belongs to Content-Disposition) so they can be excused in a way....
Message was edited by:
user464123

Content-Type & Content-Disposition

I have received a request from a company that I work for and I have no idea how to address this issue. Since this board is so Mac-saavy, I figured someone could help me with this. This is the request:
**On your e-mails, there are 5 lines of computer stuff called Content-Type, and 2 lines called Content-Disposition. Those lines are pushign the attachment line way down to the bottom of the printed page. I need to see that attachment line above the fold when I fold the printed page in half. Please talk to your service provider about how to eliminate those lines.**
Any guidance would be appreciated. Thanks!

You have no control over this. There may be less of it (I am not sure) if you use plain-text rather than rich text when composing your messages.
The puzzling thing is why it is showing when your recipient prints the messages; most mail clients would, by default, suppress these headers when viewing and printing.
Suggest that he print with smaller font on bigger paper; that should bring the attachment line above the fold
AK

Error #2190: The attempted load of failed as it had a Content-Disposition of attachment set.

I'm getting this error when I set the URL.
Error #2190: The attempted load of http://site.com/get_file_content.php?id=1000 failed as it had a Content-Disposition of attachment set.
Is there a way to force the content type on the client?
Here is the code I'm using:
            var resource:URLResource = new URLResource(path);;
            var element:SWFElement = new SWFElement(resource);
            mediaPlayer = new MediaPlayer();
            element.resource.mediaType = MediaType.SWF;
            mediaPlayer.media = element;
            mediaPlayer.addEventListener(MediaErrorEvent.MEDIA_ERROR, mediaErrorHandler);
            mediaPlayer.addEventListener(MediaPlayerStateChangeEvent.MEDIA_PLAYER_STATE_CHANGE, mediaPlayerStateChangeHandler);
            mediaPlayer.addEventListener(DisplayObjectEvent.DISPLAY_OBJECT_CHANGE, mediaPlayerDisplayObjectHandler, false, 0, true);
            protected function mediaPlayerDisplayObjectHandler(event:DisplayObjectEvent):void {
                var displayObject:DisplayObject = event.newDisplayObject;
                displayObject.width = 400;
                displayObject.height = 250;
                uicomponent.addChild(displayObject);
            protected function mediaErrorHandler(event:MediaErrorEvent):void {
                trace(event.error.detail);
                // Error #2190: The attempted load of http://site.com/get_file_content.php?id=1000 failed as it had a Content-Disposition of attachment set.
Message was edited by: thx1138

The problem is that the server script is treating the request as a request for a file to download, rather than as a typical HTTP request/response. You need to modify the server script so that it doesn't include the Content-Disposition header, there's not much you can do on the client side.

Content-Disposition inline/attachment

I am using Content-Disposition for excel file download as below:
I have searched the forum but not able to get the exact answer or solution. Please also guide me to some url if possible.
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-Disposition", "inline; filename=xyz.xls" );
If I am using inline attribute but I am not able to specify the filename as xyz.xls and by default fileName provided by browser is the request URL(action-mapping in case of struts).
But it works fine with attachment attribute and prompts for the exact file Name and works fine.
I want to know how to specify the desired fileName with inline Attribute ? I am using the struts based request for Excel file generation.
Best Regards,
Amber Gupta

if You dont't mind , I just want to tell u something on this code.
If im wrong, Please tell me why? and what is the best way of acheiving it then,
the code below loads whole filedata and it does not matter how big the file is. Don't you think that it will heat up the memory by doing so. and consider the method what he was doing is perfectly right. but is there any other solution/wrong with above code what MR/ms/Mrs Kenneth has written like.
I just wanted to know the answer what is the wrong with MR. Kennth Code since i looked at it as a perfect working code(but with some glicth).
with Regards
Lokesh T.c
FileInputStream in = new FileInputStream(fileToDownload);
ServletOutputStream out = response.getOutputStream();
int bytesRead = 0;
byte byteArray[] = new byte[fileTODownload.length()];
// Read in bytes through file stream, and write out through servlet stream
/*while( ( bytesRead = in.read( byteArray ) ) != -1 ) {
out.write( byteArray, 0, bytesRead );
in.read(bytesArray,0,fileTODownload.length());
out.write(bytesArray,0,fileTODownload.length());
in.close();
out.flush();
out.close();

Download File by url in another server? (Content-Disposition","attachment)

Can the file be downloaded by a url in another server?
ie.
Server A: JSP program
Server B: filepath + filename = "http://xxx.com/xx/x.doc"
e.g.
    response.setContentType("APPLICATION/OCTET-STREAM");
       response.setHeader("Content-disposition", "inline" );
       response.setHeader("Content-Disposition","attachment; filename=\""+ fn.trim() + "\"");
          java.io.FileInputStream fileInputStream =new java.io.FileInputStream(filepath+filename);
          int i;
          while ((i=fileInputStream.read()) != -1) {
                  out.write(i);
          fileInputStream.close();
          out.close();

I tried this but it doesn't work. In the report column it shows up as Download" >_ .
This seems to indicate that the href code is not being interpreted correctly.
Following is exactly what I have in the URL field:
<a href="#OWNER#.DOWNLOAD_MY_FILE?p_file=#NOTIFICATION_SEQ_ID#&v_type=SUMMARY">Download</a>Yes, I have granted execute rights to the procedure.
Thanks,
Dale

Content-Disposition in IE

Hi
I want to stream a pdf file and then show in the browser . res.setHeader("Content-Disposition", "inline;filename=temp.pdf;");
This works with netscape but in IE it shows blank page after starting a Acrobat process.
But if i use
res.setHeader("Content-Disposition", "attachment;filename=temp.pdf;"); this works with IE and netscape both . I am not able to figureout what is the problem . Anyone knows solution for this problem ? Please let me know .
Thanks in advance
Amit Kumar

Hi
I want to stream a pdf file and then show in the
he browser . res.setHeader("Content-Disposition",
"inline;filename=temp.pdf;");
Hi,
I am currently working with reports being exported to excel
You can try this :
res.setContentType("application/pdf");
I think it should work ....but I am not sure whether the mime type for pdf is ("application/pdf"); or ("application/vnd-pdf");
try both ....let me noe if fit works ....:)
cheers

Bug: DocumentManager does not emit Content-Disposition header

Good afternoon,
I have a process with an output variable of type Document: this document has a defined filename. When invoking the process, instead of downloading the file with the defined filename, I was receiving a file with a name that looks like an MD5 hash.
The fault for this lies with the DocumentManager application: it does not emit the content disposition header that would suggest to the browser what the real name of the octet-stream is. As such, without this header, the user agent will assume that the file-name is the endpoint name.
The trace of the HTTP exchange is below:
GET http://HOST:8080/rest/services/APP/SERVICE:1.0?q=83
Cache-Control     no-cache, must-revalidate
Date              Wed, 17 Nov 2010 12:54:29 GMT
Pragma            no-cache
Transfer-Encoding chunked
Location          http://HOST:8080/DocumentManager/docm$(NUMBER)/$(HASH)?type=$(TYPE)
X-Powered-By      Servlet/2.5 JSP/2.1
GET http://HOST:8080/DocumentManager/docm$(NUMBER)/$(HASH)?type=$(TYPE)
Date              Wed, 17 Nov 2010 12:54:35 GMT
Transfer-Encoding chunked
Content-Type      application/vnd.ms-excel
X-Powered-By      Servlet/2.5 JSP/2.1
The 2nd HTTP request should have included the specified header, like so:
Content-Disposition: attachment; filename=MyExcel.xls
RFC 2183: The Content-Disposition Header Field
Best regards,

Hi Robert,
thanks for the reply. This is certainly a different aspect of the problem. The HTTP response that serves the dynamic portion (the one with the timestamp) has the response headers:
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2015 18:05:53 GMT
Server: Apache/2.2.29 (Unix)
X-Powered-By: PHP/5.3.29
Cache-Control: max-age=100000, public
Keep-Alive: timeout=3, max=95
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
So it is marked as cacheable.
My expectation now is this:
- when clicking the "refresh" link in the markup, there should be no new timestamp. Reason is that the dynamic part should have been cached and I would expect the XSLT engine to use the browser's caching layer when fetching fragments
- when hitting "F5" I would expect a revalidation request to be send to the server (e.g. max-age=0 or if-modified-since). Then the server can revalidate the fragment. In my example case the fragment would be served in any case, so I would expect a
new timestamp
- when hitting "CTRL+F5" I would expect a request with "cache-control: no-cache" that enforces the server side caches to always return new content. I would expect a new timestamp in this case.
What I observe is that:
- Chrome and FF work as expected
- IE (10/11) will always fetch the dynamic fragment, so I will even see a new timestamp when clicking the refresh link. Also the "if-none-match" header in the "F5" case is NOT forwarded to the dynamic fragment (potentially because it is
not cached in the browser at all)
Carsten

ParseException Content-Disposition filename spaces

Hello All,
I have an email generated from Thunderbird 1.5.0.9 (Windows/20061207) which contains an attachment whose filename has spaces.
JavaMail (1.4) throws a javax.mail.internet.ParseException on the MimeBodyPart.getDisposition() call:
javax.mail.internet.ParseException: Expected ';', got "-"
javax.mail.internet.ParameterList.<init>(ParameterList.java:179)
javax.mail.internet.ContentDisposition.<init>(ContentDisposition.java:87)
javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:1039)
javax.mail.internet.MimeBodyPart.getDisposition(MimeBodyPart.java:299) The offending attachment part has a part header which looks like this:
Content-Disposition: inline;
filename*0=Test - Test.pdf
Clearly the parser is failing due to the spaces in the filename. Bugzilla for Thunderbird (Bug 221028 - https://bugzilla.mozilla.org/show_bug.cgi?id=221028) discusses this issue, however the status of the bug is VERIFIED WONTFIX.
According to the Mozilla discussion, their implementation is conformant to the RFC:
...Just two days ago I was talking about this issue in #mozillazine with Christian
Biesinger and Boris Zbarsky, and they said that this is the proper behaviour
according to the RFC...
Whether it IS conformant to all relevant RFCs I don't know, but it seems it won't be changed any time soon.
This issue also exists for the Content-Type header in the same email which has the same format:
Content-Type: application/pdf;
name*0=Test - Test.pdfAnyone know if there is a way I can "safely" parse these headers? Is this a JavaMail bug?
Thanks

Absolutely, and please don't take my posting as a complaint - well over 99.9% of our emails are consumed flawlessly. I'm expressing more of (my opinion only) a high-level philosophical argument about of why I think good software (JavaMail) should try to by-default interact with not-so-good software. I'm not basing this not on "technical correctness", but rather the following unfortunate scenario:
One particular example would be certain products made by a company with the initals "MS". These products almost always hide brokenness (they act as highly liberal consumers). Outlook, Internet Explorer, are the 2 primary examples. So a user (and unfortunately most users have never read or care about an RFC) opens the email with Outlook, or the web page with Explorer, etc. It "works". Now, we programmers certainly know better, but remember that we aren't buying or choosing products or services, we're offering them. User then opens with Java-based product (stack trace). User buys or chooses MS-based product, MS-based product retains market stranglehold, commercial email providers test their products with Outlook, and in the end, brokenness is propagated anyway. It's kind of like reverse-Darwinism for software (survival of the most-broken).
Some customers complain that JavaMail doesn't strictly enforce every requirement of the standards
As an SMTP producer, I might see that, but personally I can never recall seeing a single problem with outgoing email from JavaMail. As a client consumer, I'm not sure why they would take that philosophy, unless maybe they are using JavaMail to test RFC-compliance.
there are forms of brokenness that go beyond what can be handled at the JavaMail API level.
Of course, but I have yet to see a message that the "MS" client could not read. So perhaps they are working around some of these at a higher level (in the GUI, maybe?)
But for developers who don't think about this problem...
Most developers most likely aren't using JavaMail to read in over 25,000 emails a day. So admittedly, I'm in a unique situation.
Having made that decision it's relatively straightforward to configure JavaMail appropriately. Not really, one change required updating the jar file, others require obscure uses of the API. And a developer/administrator is only going to make those changes after seeing the problem.
to avoid propagating brokenness as you suggest.
Brokenness will get propagated anyway (see reverse-Darwinism, or the Theory of De-evolution above).
I'm looking forward to trying out 1.4.1, and thanks again for all the assistance, a very thorough FAQ, and overall a great API. I think the opensourcing was a good idea, JavaMail really is by far the best API that I have seen for this type of high-volume work.

Convergence 2.1 displaying image attachments - honoring Content-Disposition

Is it reasonable to assume that when displaying a message from within Convergence 2.1 that images (jpg for example) should be displayed based on the Content-Disposition header value? That is to say that if Content-Disposition is "inline" that the image shall be displayed in the body of the message and that if Content-Disposition is "attachment" the image shall not be visible until it is selected or some other action is taken?
The behavior I observe in Convergence 2.1 is that inline images are show inline and are also duplicated again in a "preview mechanism" at the the end of the message. Attached images are not displayed inline but are also visible in the preview mechanism at the end of the image.
Can this preview behavior be changed to explicitly honor Content-Disposition?
From RFC 2183 (http://www.ietf.org/rfc/rfc2183.txt)
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is intended to be
displayed automatically upon display of the message. Inline
bodyparts should be presented in the order in which they occur,
subject to the normal semantics of multipart messages.
2.2 The Attachment Disposition Type
Bodyparts can be designated `attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user. The MUA might instead present the user of a
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.

Convergence 2-1.01
Oracle Communications Messaging Exchange Server 7u4-21.01 64bit
However this was determined to be a bug it is listed as having the ref # 12597156.. tho I have not seen any real movement on it in the SR I put in back in May.

Specifying pdf document's name in browser - content-disposition problem

Hello ,
I want to open a PDF document in browser, which needs to have a specified filename when user tries to save it.
My web app sends an "application/pdf" document back to the browser.
I use the Content-Disposition HTTP header to instruct the browser to open the document inline, i.e. using the appropriate plugin, which is Adobe PDF in this case. When the user clicks Save As..., the document filename needs to be the one specified by the same HTTP header. Here is the code:
response.setContentType("application/pdf");
String contentDisposition = "inline; filename=\"filename.pdf\"";
response.setHeader ("Content-Disposition", contentDisposition);
response.setHeader ("Content-Length",new Long(file.length()).toString());Unfortunately this does not work for me. Document opens fine, but I can't get it to have the name I specified. The plugin uses the default name, which is the full URL of the document. I tried several combinations of HTTP headers, but neither worked. I tried putting an additional GET request parameter at the end of the URL, like ...&filename=filename.pdf , but that didn't work either.
I tried Adobe 7.0 and 8.1.2.
Any suggestions ?
Thanks a lot!

Thank you very much for your answer.
Needless to say I tried opening the document in IE, FF and Chrome, and neither worked.
I had a look at the code at your web site, and saw that you were serving files for direct download: Content-Dispositoin:attachment... .
This works fine for me too, and the filename is recognized correctly in that case. The problem is, I want to display the PDF inline...
My server is not configured for URL rewriting, and I would be probably quite some problem to make this app work with it, so the /filename.pdf is not an option for me.
Edited by: matavulj on Sep 25, 2008 7:21 AM

How to specify the charatcer encoding for the parametes Content-Disposition

I want to download a file with chinese name .
response.setHeader("Content-Disposition","attachment; filename=" + fileName);
the above part of code is working fine for english file names. but i am facing problem when i try to get file with chinese name .
The pop up window is not defaulting with the chinese name .
When i searched for net , in one rfc it was specified how to do that one.
http://www.faqs.org/rfcs/rfc2184.html.
I tried it but .. could not able to solve the problem.

Hi,
Am facing similar problem with russian and japanese characters in file name.
I tried the UrlEncoder.encode(filename, "utf-8') api to encode the file name. This worked fine with IE but firefox and safari shows junk for japanese/russian characters.
Anyone having an idea abt this?
Thanks,
Kapil

HTMLLoader & Content-Disposition of type attachment

Similar Messages

Maybe you are looking for