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

Similar Messages

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.

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.

Setting the title for File download dialog when using content-disposition

I am trying to send a file from server to client (browser). I am setting the content type of the resopnse and using the "content-disposition" header and giving the filename.
But the issue is, when it is downloading and the dialog box is showing the progress bar, The title of the dialog box is showing something like "40% of localhost:9080.....". It doesn't show the file name in the title bar. Also, if the URL is very long (I am passing some get parameters and the servlet name is also long), I get junk characters like small boxes.
How to set this title in the servlet?

Is there a reason why you have to use FileReference.Save versus File.browseForSave? In Adobe AIR, the File class, which extends the FileReference class, provides more capabilities and has less security restrictions than the FileReference class. Using File.browseForSave, it has a title:String parameter which is a string that is diplayed in the title bar of the dialog box.

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

Upload file - get rid of Content-Disposition: form-data;

Hello,there.I just want to know if somebody had succesfully solved problem of getting rid of rows
at uploaded file
-----------------------------7d23c05be8
Content-Disposition: form-data; name="fromflr"; filename="C:\WINDOWS\Desktop\Clock"
Content-Type: text/plain
"Some Data"
-----------------------------7d23c05be8
Content-Disposition: form-data; name="toflr"
HARGAL
I just need get rid of rows like
-----------------------------7d23c05be8
Content-Disposition: form-data; name="toflr"
HARGAL
and leave only "Some Data" in uploaded file.
Any suggestion would be appreciate.

See for example Upload taglib from Coldtags suite:
http://www.servletsuite.com/jsp.htm

Content-Disposition not working!

Hi!, I've a servlet which its purpose is to read a file and write it later using a ServletOutputStream. This file must not be wrote as text, but instead the idea is to write it and then browser open it with a specific application. The extension of this file is already asssociated with the program that I want to use to open it. In fact, if I use a url link to the file, the browser requests the application and all goes fine, but I want that this application runs inside the browser, so I'm using content-disposition: inline; in order to do this, but I can't make it! The browser always try to download the file. My code is this:
import java.util.*;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class imflpruebas extends HttpServlet{
     private ResultSet rs, rs2;
     private Connection connection;
     private Statement statement;
     public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{
          doPost(request,response);
     public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{
          response.setHeader("Content-Disposition","inline");
          response.setContentType("application");
          String sFileName = "F:\\jakarta-tomcat-4.1.24\\webapps\\ImaxFileWeb\\temp\\reno_PRUEBA_0_0_0.IMX";
          File file = new File(sFileName);
          byte[] byteContents = new byte[(int)file.length()];
          FileInputStream in = new FileInputStream(sFileName);
          int retcd = in.read(byteContents);
          in.close();
          ServletOutputStream out = response.getOutputStream();
          out.write(byteContents);
          out.flush();
          out.close();
}          I've tried to put the content type before the set header and the result is the same.
Any ideas?
Best whishes
Raul

Hello Raul,
There are a few things to consider. First of all, how do you want the browser to tell which application to use. Your content-type is very non-specific so the browser would never be able to tell by itself. Using a mime-type which has been mapped to an application might do a lot.
Second, if you are using IE mime-types have little influence. IE tries to recognize the data by looking at the raw bytes and see if it recognizes the format. If not, IE will look at the URL and determine what to do with the data based on the URl extension. So if you have a link http://..../xxx.xls IE will try to show the data using Excel (if installed obviously). Adding such an extension (that can be ignored by the servlet) can do the trick with IE.
If using IE check the Windows Explorer file settings (based on extensions). There is an "advanced" property called "confirm open before download" which should be cleared to allow an automatic open. Clearing the check "always ask before downloading" on the browser popup has no effect at all.
Hope this helps.
Regards,
Silvio Bierman

Content-Disposition inline Not working

Hi all,
I am using Orion application server as Web server. I like to open a file in client side form the server. Which one is known MIME type. I don't want the IE to prompt the user for Save as/ Open from the current location.
I am using "inline" argument in Content-Disposition header. Eventhough i am getting promt dialog box in client side.
The following is my code.
<%@ page import="java.io.*" %>
<%@ page import="java.net.*" %>
<% response.setContentType("application/pdf"); %>
<% response.setHeader("Content-Disposition" , "inline;filename=test.pdf" ); %>
<%
String fileURL = "http://java1/examples/jsp/test.pdf";
     ServletOutputStream sout = response.getOutputStream ();
     URL url = new URL ( fileURL );
     BufferedInputStream bis = null;
     BufferedOutputStream bos = null;
     try {
          URLConnection conn = url.openConnection();
          // Use Buffered Stream for reading/writing.
          bis = new BufferedInputStream(conn.getInputStream());
          bos = new BufferedOutputStream(sout);
          byte[] buff = new byte[2048];
          int bytesRead;
          // Simple read/write loop.
          while(-1 != (bytesRead = bis.read(buff, 0, buff.length))) {
               bos.write(buff, 0, bytesRead);
     catch(Exception ex){
          System.out.println(ex.toString());
%>
Any one give the soloution for this problem. I hope there is no problem with the source code. I want to avoid the dialog box while downloading in the client side.
Thanks
Prabhu.

Hi,
Please let me know in which browser you are trying to do this, since it as some problem with IE5. You can try this, using the Netscape browser which doesn't have any problem.
Hope this helps.
Senthil Babu J

("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

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.

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

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.

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.

Making HTTP requests with content-disposition

I need to write a Java app that can access a web server that returns most content as files (ie. using content-disposition).
Previously I have used something like this to make HTTP GET requests to return files on a web server.
��String strUrl = "http://www.yahoo.com/index.html";
��URL url = new URL( strUrl );
��URLConnection conn = url.openConnection();
��InputStream in = url.openConnection.getInputStream();
��byte[] buf = new byte[conn.getContentLength()];
��in.read( buf, 0, getContentLength() );
This doesn't seem to work when the HTTP header has "content-disposition". Here is the header returned by the web server.
��Server=Microsoft-IIS/4.0
��Date=Thu, 04 Jul 2002 13:18:53 GMT
��Content-Disposition=filename=file.xyz
��Content-Type=text/html
��Cache-control=private
��Transfer-Encoding=chunked
��content-length=30306
The number of bytes actually read (as returned by in.read()) is less than the number of bytes as indicated in the content-length.
How can I handle this?
Mike

I have managed to discover that an incorrect content-type header is causing the problems that I have been encountering with file downloads from a web server.
As I mentioned in a previous post the content-length header was not a good indicator of file download success.
My program downloads pictures from the internet, almost always in .jpeg format. I have found that files are successfully downloaded only when the content-type header contains the words: image/jpeg. In some instances although I am trying to download a picture file the http content-type header is stated as being: text/html.
In those instances where text/html is given as the content-type file download fails in so far as the files are not acutally viewable on the native system (Windows varieties in my case).
To determine the error I used the following code:
URLConnection urlConnect = myURL.openConnection();
System.out.println("Http Header, Content-Type: "+urlConnect.getContentType());
System.out.println("Http Header, Content-Length: "+urlConnect.getContentLength());Even though content-length mostly corresponded with the downloaded files length, if the Conten-Type header was wrong then the file was all but useless.
Regards
Davo

Content-Type & Content-Disposition

Similar Messages

Maybe you are looking for