how to override “cache-control” values in a HTTP response
I have a web page that returns the following header when I access material:
Cache-Control:no-cache, no-store
Using a firefox extension (like force cors I can't get it working )
I want to modify this response header so that the material is actually cached instead of wasting bandwidth.
I have recently spent some hours on trying to get a file cached, and discovered that the chrome.webRequest and chrome.declarativeWebRequest APIs cannot force resources to be cached. In no way.
The Cache-Control (and other) response headers can be changed, but it will only be visible in the getResponseHeader method. Not in the caching behaviour.
From some reddit thread:
Install "Modify Response Headers" addon for FF:
https://addons.mozilla.org/en-US/firefox/addon/modify-response-headers/
In the addon's options, go to headers. Select Action -> Filter. In
the header name field, type cache-control, then click Add. Do
the same again but with the header name pragma. Then click the
Start button (big button on the top-left).
Set these values in about:config: browser.cache.disk.enable = false
browser.cache.memory.capacity = 200000 (you will probably need to
create this field - right click empty space -> New -> Integer)
Restart Firefox.
Related
I've seen many applications substitute "#" when they wish to satisfy href property of the an anchor tag. While I understand how it operates, is it valid to say that urls of the form:
http://somesite.com/resource.html#
and
http://somesite.com/resource.html
are equivalent? If not, what does an empty value for the # signify? I've most often seen browsers interpret this as "top of page".
The hashtag # is a client side only fragment identifier. The symbol refers to an identifier inside the content. That content can be either text/html or XML.
A URL address like http://somesite.com/resource.html# ends with an empty fragment identifier. Empty fragment identifiers are not technically valid, but are valid URL addresses.
The browser will not match <div id="">....</div> using an empty fragment.
Instead the browser treats the empty fragment as an invalid identifier. So it is ignored. It does not specify a point to the top of the page. If you open a URL address that ends in a # empty fragment, scroll down to the bottom and click refresh. The browser will not refresh to the top of the page. It will refresh to the current location.
Fragments can be used in browsers for custom content types. Such as applications or PDF documents.
Summary of info in the specification for URL parsers:
The # will set the URL's fragment to the empty string and essentially tells the parser to expect a fragment string (which may refer to a specific region of the page). If the URL ends at that point, the fragment is still the empty string, and the result in the browser should be as if the # did not even exist in the URL.
So a trailing # doesn't so much specify "top of the page" as it produces what should be the behavior of the browser parsing a URL without the trailing #
This is a code, generated from my .NET 3.5 application :
<input type="text"
rel="0,00 €"
id="ctl00_ContentPlaceBody_ImpostaCompravenditaImmobili1_txtRenditaCatastale"
value="0,00 €"
name="ctl00$ContentPlaceBody$ImpostaCompravenditaImmobili1$txtRenditaCatastale">
Now, when I load it, and through Firebug (but this doesn't matter really, with whatever debugger you use you can do this) I add/delete (for example) disabled="", and I refresh the page (by hitting F5), on the server side it stores this value. And in the page I get after the refresh, the value has been stored in the (I believe) context View of the page.
Is it a bug? Normal behavior? I found it really bizarre!
This behavior doesn't depend on FireBug or a similar plugin. It depends on a browser.
I was able to reproduce this with my Firefox 10.0.1 (I also was able to reproduce this with earlier versions of FF): I added extra chars to my textbox, then pressed F5 and the text in that text box wasn't changed. But after doing a Ctrl - F5 the value in my textbox resetted to the default value.
A simple test shows that FF set the Cache-Control: max-age=0 header when F5 is pressed.
Doing a Ctrl - F5 sent these headers: Pragma: no-cache and Cache-Control: no-cache.
I also was able to find a workaround for this on the server side by using:
Response.Cache.SetNoStore();
This will add Cache-Control: no-store to the response headers (it means do not store any part of either this request or any response to it.).
For a breakdown of other browsers behaviour, check out this answer.
Is it a bug? Normal behavior?
When I faced this first time it was really unexpected to me too.
i have an action that return a file content. i added:
Response.AddHeader("Content-Disposition", "attactment; filename:\"" + survey.File + "\"");
so that the image would be opened in another tab/page, gets opened in the current tab/page.
whats wrong with the header?
The content-disposition header instructs the user agent how it should present the data, and it is usually used when serving up binary data (as opposed to plain text). When set to "attachment", the display of the content is contingent upon further action of the user. In other words, the user should receive a prompt and must decide what to do with the content (usually given an "Open" or "Save" option).
You can not programmatically force a hyperlink to open up in a new tab. Even if you could, you should not. This behavior should be controlled by the user agent. As a user, when I want to open something in a new tab, I use the mouse-wheel-click because that is how my browser is configured.
You cannot control browser's tab behaviour by using HTTP headers - there is nothing in your code that affects this.
What might help you is changing HTML code that points to your download - if you are using tag you can set its target attribute to _tab or _blank and it will work in many browsers.
I've got an ASP.NET ashx class that retrieves data from a database, creates a PDF file using iTextSharp, and streams the PDF to the browser. The browser (IE and Firefox at least) is launching Acrobat Reader as a separate window to open the file. I'd like for it to display inline within the browser.
Is that something I can completely control from the server side? I'm already setting the Content-Type header to application/pdf, and I've tried setting Content-Disposition and Content-Length. Nothing so far has worked.
Is there another header I'm missing? Is there something in the PDF itself that tells the browser how to display it? Any other ideas?
Setting the content-disposition and content-type headers should do it, but you might also need to call Response.ClearHeaders() to clear other headers that have been set.
Also, try using Fiddler to see the actual headers and content from the response and compare them to those from a site that works like you want.
If you are using an ashx (web handler) try this:-
context.Response.AddHeader("content-disposition", "inline; filename=Something.pdf")
OK, turns out it was a stupid question, but I'm glad I asked it because I had never heard of Fiddler (which led me to the answer, which is why I'm accepting tspauld's answer). The PDF is generated by a web service that serves the file to a couple of different front-end sites. I was setting the content disposition to inline in the service, but that didn't matter, because the browser never got that header; it got the header from the front-end site (which was attachment). I changed it in the front-end site and that fixed it.
So the answer is that you have to have Content-Type=application/pdf and Content-Disposition=inline; filename=Something.pdf, as others have said.
Try generating them into your page using html OBJECT.
<OBJECT WIDTH=640 HEIGHT=480>
<PARAM NAME="SRC" VALUE="<%=filePath%>">
<EMBED SRC=<%=filename.pdf%> WIDTH=1000 HEIGHT=680>
<NOEMBED> PDF should have displayed here!</NOEMBED>
</EMBED>
</OBJECT>
If you need to stream the response with an ashx instead of being able to return an aspx, I think you may be out of luck.
Otherwise, I believe the settings to show in browser or not, is completely client driven and out of your hands.
So, I have a sample in one of my works that is what you need:
<cc1:ShowPdf ID="ShowPdf1" runat="server" BorderStyle="None" BorderWidth="0px"
Height="750px" Style="z-index: 103; "
Width="750px"/>
and in server side :
ShowPdf1.FilePath = String.Format("~/Handlers/Pdf.ashx?id={0}#view=FitH&page=1&pagemode=none&navpanes=1", myPublicationId);
I place here also some code from my PDF Handler :
Response.ContentType = "application/pdf";
byte[] bytes = YourBinaryContent;
using (BinaryWriter writer = new BinaryWriter(context.Response.OutputStream))
{
writer.Write(bytes, 0, bytes.Length);
}
Anyway If my post doesn't seem clear to you, have a look at this sample How to Display PDF documents with ASP.NET
I think this header will do what you want
Content-type: application/pdf
Since you say that is not working, then I suspect it is a configuration setting on the client side.
Check your installed version of Adobe Acrobat. There is a setting in preferences for "Internet" and a checkbox that says "Display PDF in Browser".
--
bmb
Here is an article on using the embed tag to do it:http://blogs.adobe.com/pdfdevjunkie/2007/08/using_the_html_embed_tag_to_di.html
If you have the budget, my company sells a set of products that includes an AJAX based image viewer that will let you view the PDF pages in line without Acrobat at all. In its simplest form, it is just a viewer, but you can layer in interactivity as you need.
Response.Write("<script language=\"javascript\">window.open( with https and pdf
What we do in a Asp.Net 1.1.4332 application is the following:
a button triggers a server event that does some processing and puts the data in a session object after that the following code is executed :
string page = Request.ApplicationPath + "/ApkRapportPage.aspx";
Response.Write("<script language=\"javascript\">window.open('" + page + "','_new');</script>");
this opens a page that streams a pdf to the new browser window
basically with the following code ( I know stuff is missing here, but that doesn't really mater for the question)
byte[] pdfbytes = Convert.FromBase64String(rapportB64);
Response.ClearContent();
Response.ClearHeaders();
Response.Buffer = true;
Response.ContentType = GetContentType(format);
string header = GetContentDispostionHeader(fileName, format, type);
Response.AddHeader("Content-Disposition", header);
Response.BinaryWrite(pdfbytes);
Response.End();
Okay this code works !
Just not in IE6 and IE7 when using HTTPS
When using IE6 with HTTPS it results in a save-as dialog (not a pdf that opens in a browser)
When using IE7 with HTTPS it results in a blank screen
When using Firefox it works just fine
If I simulate the extra server side processing in the page_load to put the required data in the session and replace the button with a link that opens the same pdf generating page in a new window, the code works.
For the actual application it is not an option to get the required data before the button is clicked.
So I would really like to get the following code to work
string page = Request.ApplicationPath + "/ApkRapportPage.aspx";
Response.Write("<script language=\"javascript\">window.open('" + page + "','_new');</script>");
Questions:
Does anybody know why this code doesn't work in IE6 and IE7 when using HTTPS ?
What is needed to get the code to work ?
Extra info:
I tried not using response.write but
just a javascript window.open behind
the button, this has the same effect
when googling for pdf streaming, you can find a lot of people having
trouble with this, mostly they set
header lengths or other properties or
static file compression flags in IIS.
I am pretty confident I tried them
all.
Adobe acrobat reader settings, browser settings or any other client
side settings don't seem to be the
problem. Tested on different
machines, with http works, with https
it doesn't.
Switching between https and http might have something to do with this,
but when I set IE to tell me when I
am switching, no switching seems to
occur during testing.
When replacing the window.open part with a response.redirect then the code also works, just not in a new window
Any help would be greatly appreciated !
As requested the headers, as shown by Fiddler:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 05 Mar 2009 14:18:36 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Content-Disposition: Inline;filename=APKrapport.pdf
Cache-Control: private
Content-Type: application/pdf; charset=utf-8
Content-Length: 28307
Getting attachments to open the way you want has everything to do with the headers you send. If you locate to an .aspx page that you want to act as a dynamic PDF resource these HTTP headers become increasingly important.
This website states a number of reasons why it might not work in IE.
Set the content-type of the response to "application/pdf", ex. response.setContentType("application/pdf");
Add a dummy parameter on the end of the url, like:
http://x.y.z/DoGenCompStmt?filename=dummy.pdf
because IE ignores content-types, so you need to give it a hint, and the ".pdf" extension is an easy way.
Set the "content-length" on the response, otherwise the Acrobat Reader plugin may not work properly, ex. response.setContentLength(bos.size());
An additional thing that seems to help some IE browsers is to also have : response.setHeader("Content-Disposition", "inline;filename=somepdf.pdf");
EDIT: since you already tried all of the above i can only point you to the rfc for content disposition which to my knowledge is the only way to tell a browser how to deal with binary content.
EDIT: what would really help is to see the HTTP Headers it currently returns when you try to open the pdf in the browser. Fiddler does a great job at catching traffic
You'd be better off using a generic handler (.ASHX) to serve this sort of content, rather than trying to force a web-page to serve content other than HTML.
After a lot of trial and error I found a working solution, still not sure why the other code doesn't work.
This code works:
StringBuilder js = new StringBuilder("<script language=\"javascript\">");
js.Append("_window = window.open(\"\",'_new');");
js.Append("_window.document.open(\"application/pdf\");");
js.Append("_window.location.href = \"ApkRapportPage.aspx\";");
js.Append("_window.document.close();");
js.Append("</script>");
Response.Write(js.ToString());
Must have something to do with the mime type.
It has a problem though. When IE is set to show when you switch between HTTP and HTTPS this code will give that message twice. The following code doesn't switch but causes the page load of ApkRapportPage to be fired twice.
StringBuilder js = new StringBuilder("<script language=\"javascript\">");
js.Append("_window = window.open(\"ApkRapportPage.aspx\",'_new');");
js.Append("_window.document.open(\"application/pdf\");");
js.Append("_window.location.href = \"ApkRapportPage.aspx\";");
js.Append("_window.document.close();");
js.Append("</script>");
Response.Write(js.ToString());
If you are getting a blank page when trying to view a PDF inline in the IE7 browser and you are using Acrobat version 6. Update your Acrobat version to resolve problem.
Note that this problem is unrelated to HTTPS, the same problem (and the same fix) applies for HTTP.
The fix works because the problem with IE is that it doesn't display PDF in a script-opened window if the PDF is loaded at once. (Unknown why, but this is the core of the problem, and the fix.)
I notice that your returned content-type is hosed
"Content-Type: application/pdf; charset=utf-8"
When you stream the content to the aspx page ensure that you set the
Response.charset = ""