I have a default page that can display 3 different contents depending on whether:
The user is not logged in
The user is logged in but hasn't set something up yet
The user is logged in and has set something up
What's happening is that (1) and (2) will sometimes be displayed when it should be the other one. After I ctrl-r, the correct version displays.
This is nothing to do with the browser back button, it happens after clicking a menu option to go to the default page or performing some action that takes the user to the default page.
I also have a route set up for the page such that it's possible to append it with a username. eg: http://www.example.com/user1234
I mention this in case it may have something to do with it.
This is what I've tried to stop the caching:
<%# OutputCache Location="None" VaryByParam="None" %>
That didn't work so I tried (in Page_Load):
Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache)
Response.Cache.SetNoStore()
Any ideas what I'm doing wrong?
ETA
As per a couple of comments, I tried it in Chrome incognito mode and there is no problem. I tried with the console open as well to see the headers but unfortunately the problem goes away then. Here's the headers anyway:
Request
GET / HTTP/1.1 Host: localhost:2873 Connection: keep-alive
Cache-Control: max-age=0 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.92 Safari/537.36 Referer: .../signin
Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8
Cookie: ...
Response
HTTP/1.1 200 OK Cache-Control: no-cache, no-store Pragma: no-cache
Content-Type: text/html; charset=utf-8 Content-Encoding: gzip
Expires: -1 Vary: Accept-Encoding Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319 X-SourceFiles: =?UTF-8?B?...
X-Powered-By: ASP.NET Date: Thu, 27 Mar 2014 20:17:39 GMT
Content-Length: 3045
ETA2
I've been testing in Chrome and I've just found out there's no problem in FireFox.
If I login/out/in/out... there is no problem
If I login/out then log in with the wrong password a couple of times (causing postbacks in the login page), and then log in again correctly, it always displays the incorrect logout page in Chrome.
I was having the same problem. What I did was place this
Response.CacheControl = "No-cache";
within the page load before any of the other code runs. The issue that this solved for me was similar tor yours. When a user logs in, a drop down box is loaded with different stores that the user belongs too. If I changed their stores, they could navigate back to the page and see their old set of stores. I placed the above in the page load and this solved my issues within IE, Chrome and Firefox. Hopefully something as easy as this will fix your problem.
To resolve the caching issue with particular file you have to add
<location path="WebForm1.aspx">
<system.webServer>
<caching enabled="false" enableKernelCache="false" />
</system.webServer>
</location>
into your web.config's configuration section.
You can also do it using IIS. Steps to setup no cache using IIS is as below.
Go to your sites Content View. Right click on file and switch to features view.
With file selected open Output Caching open from IIS.
From Action Pane on right side click on Edit Feature Setting, and from dialog box untick Enable cache and Enable kernal cache. Click Ok to save setting into web.config.
take a look here and checking if it could be hopefull http://dotnet.dzone.com/articles/programmatically-clearing-0
Related
In an MVC5 project we encounter a problem with caching of the bundled resources (js/css).
According to the mvc docs, by default the bundles should be cached. And it works in other projects. However, here, no matter what configurations, the response headers for our resources are
Cache-Control: no-cache, no-store
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/javascript; charset=utf-8
Date: Wed, 01 Jul 2015 11:22:11 GMT
Expires: -1
Keep-Alive: timeout=5, max=100
Pragma: no-cache
Server: Microsoft-IIS/8.5
Transfer-Encoding: chunked
Vary: Accept-Encoding
I can't figure out where this is coming from as we are not disabling cache anywhere. Any ideas?
As I suggested in the comment Igor claimed that in Global.asax there were code for disabling caching:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
Response.Cache.SetNoStore();
Igor just to inform you these lines is one of the suggested way to fix 'browser back button' scenario (but as you can see with some cons). Simple scenario steps:
Login to application - looged in user is redirected to the home page
Logout - user redirected to the login page
Click back browser button - User should not be redirected to the home page but with enabled caching it could be an issue.
Please check the back browser button funcionality. If the scenario which I wrote is a problem for you please just use atribute
[OutputCache]
with proper parameters.
Regards Piotr
I followed this tutorial, http://symfony.com/doc/current/cookbook/controller/error_pages.html, and have error.html.twig and error.json.twig within app/Resources/TwigBundle/views/Exception/
Even though the content type of the request is set to application/json, all errors default to the html version of the error page.
The format of the route is also defined:
http://symfonyinstall/api/v1/users.json
Request Header:
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Origin: chrome-extension: //rest-console-id
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19
Response Header:
Status Code: 404
date: Sun, 29 Apr 2012 06:54:35 GMT
Content-Encoding: gzip
X-Powered-By: PHP/5.3.10
Transfer-Encoding: chunked
Connection: keep-alive
Server: nginx
Content-Type: text/html; charset=UTF-8
cache-control: no-cache
I'm out of ideas... and I really need a json version of the errors for my API to work...
I just hit the same problem, and although your question is quite old and symfony bumped a few versions up since then, the problem is still relevant, so even if you don't need to know it any more, maybe somebody else will.
Your original problem was probaly caused by error described here, but there wasn't much going on about it after initial post. Since then the entire codebase was updated, so while the same symptoms reappeared, the error is not related. I am posting it here because anybody looking for an answer these days will probably find this question (as I did :).
Even when returing JsonResponse directly form kernel exception handler, it will still have Content-Type: text/html; charset=UTF-8. This stumped me so much that I used netcat to make a manual request without any smart software in between, and it turns out that the response in such case has actually two different Content-Type headers:
HTTP/1.0 500 Internal Server Error
Connection: close
X-Powered-By: PHP/5.5.9-1ubuntu4.17
Content-Type: text/html; charset=UTF-8
Cache-Control: private, must-revalidate
Content-Type: application/json
pragma: no-cache
expires: -1
X-Debug-Token: 775c55
X-Debug-Token-Link: http://127.0.0.1:8000/_profiler/775c55
Date: Thu, 27 Oct 2016 23:08:31 GMT
Now, double Content-Type header is not something you see everyday. It seems that this is implemented in Symfony\Component\Debug\ExceptionHandler class that is only used in debug mode. In order to be as robust as possible, it first renders standard Symfony error page that describes thrown exception. Rendered content is not sent back directly, instead it leverages PHP's output buffering feature to buffer and store produced output. Then it attempts to produce custom error page from framework. In case this fails, previously prepared message is sent.
Output buffering however works only for message content, and not for headers - these are always sent directly. This problem only appears in debug environment, and unusual content types on error are only common in WebAPI, where debug mode is arguably of little use. This makes exposure surface relatively small, but if an application that offers both WebAPI and end-user interface needs to be tested, this might become a problem.
Solving this problem without modifying internal Symfony files doesn't seem possible. Output control sits deep within symfony kernel and doesn't offer any configuration. Anyway, I am not convinced of benefits of such solution. If anyone could explain to me what could have happened during custom exception handler that would make default handler useless in case it failed?
Maybe user code messing with ob_* functions?
When doing updates to accounts in CRM 4.0, the preview does not update unless we clear the client cache. When requesting the preview (which happens when you click the little arrow shown in the screenshot) with URL shown below, the headers shown below are returned.
GET http://crmdev/DevOrg/_grid/preview.aspx?type=1&id={755E4F74-007D-E011-A3BC-005056B6001D} HTTP/1.1
As can be seen from the headers, there is no expiration date/time on the cache.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 1006
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Persistent-Auth: false
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate <token removed>
Date: Tue, 19 Jul 2011 13:35:10 GMT
Setting the cache to expire using the method described in the following link has no effect. http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache
Does anyone have a supported fix for Dynamics CRM 4.0 regarding the caching of the preview.aspx page? Almost all other examined pages in CRM returns 'Cache-Control: no-cache', so seemingly this file overrides the output header.
ADDITIONAL INFO ADDED
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the corss tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the cross tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
I'm using a custom ashx handler to handle a file upload. When run locally, the file uploads fine.
When I use the same setup on the web server I get a "Index out of range" error.
In firebug I see the binary contents of the file in the post data and the file name is also passed in the query string.
Any one seen this before?
I`m sure its something minor, but its driving me up the wall.
Update: Made some progress. I found out that I'm getting two different errors. One from FF / Chrome and one from IE. I'm focusing on FF now, just because firebug makes debugging easier. Now I get an error "Could not find a part of the path 'C:\inetpub\wwwroot\'"
Update 2: Got this working in FF/Chrome. Turns out IE and FF/Chrome post the data differentlly.
Update 3: Here is the output of the network profiler in IE dev tool:
Request header:
Key Value
Request POST /Secured/UploadHandler.ashx? HTTP/1.1
Accept text/html, application/xhtml+xml, */*
Referer http://cms.webstreet.co.il/Secured/fileUpload.aspx
Accept-Language he-IL
User-Agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Content-Type multipart/form-data; boundary=---------------------------7db13b13d1b12
Accept-Encoding gzip, deflate
Host cms.webstreet.co.il
Content-Length 262854
Connection Keep-Alive
Cache-Control no-cache
Request body:
-----------------------------7db13b13d1b12
Content-Disposition: form-data; name="qqfile"; filename="P-Art_Page_Digital.jpg"
Content-Type: image/jpeg
<Binary File Data Not Shown>
---------------------------7db13b13d1b12--
See the (big) list of comments and replies attached to the original question. Not sure why it works now, but Elad seems to have fixed his problem.
You have to specify the name tag.
<input id="File1" name="file1" type="file" />
I am pretty sure file uploads CANNOT be done via Ajax; you need to use a regular form post.
Also make sure you have the enctype attribute set correctly on your form tag.
I have a rendered HTML page that I am exporting to MS Word and downloading on a button click.
Here is the code snippet in the button click.
` Me.EnableViewState = False
Response.ContentType = "application/vnd.ms-word"
Response.AddHeader("Content-Disposition", "attachments;filename=XXXXXXX.doc")
Response.Buffer = True
Response.BufferOutput = True`
The functionality works perfectly well in Firefox & IE when I checked in system testing environment (locally). However when it was moved on to the hosting server (production environment) the functionality is not working in IE but is still working perfectly in Firefox.
I am not sure on where to check for the exact issue. Could it be a caching related problem?
In IE it is just not opening the download window which we will obtain when the rendered HTML content type is changed and the response stream is flushed. No exception is thrown.
I received the following response header:
HTTP/1.0 200 OK
Cache-Control: private
Content-Length: 15189
Content-Type: application/vnd.ms-word;
charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 2.0.50727
Content-Disposition: attachments;filename=NewAccountForm.doc X-Powered-By: ASP.NET
Date: Fri, 18 Mar 2011 10:18:07 GMT X-Cache: MISS from Gateway X-Cache-Lookup: MISS from Gateway:808 Via: 1.0 Gateway (squid/3.0.STABLE10) Proxy-Connection: keep-alive
Is your hosted environment adding http headers? IIS could easily be configured to add headers that are messing up what you want to send out. It's actually quite common, and could be the issue. You'll need to determine this for sure, so here's a suggestion for investigating:
Try using a WebClient class and look at the Response headers.
Edit - updated
I just noticed - did you remember to put
Response.Clear();
before adding headers? It may not be the hosting environment at all. However, given that it works locally and not at your hosting environment, and assming that it is the same code, it still looks to me like something is different about the hosted environment, and the most logical option would be the headers.
I set Response.Charset = "" and always do Response.Flush(), Response.End(), and Response.Close() after I export the HTML.