I work on a web application in ASP.NET and HTML5. I have a simple page Default.aspx. In its Page_Load handler I call 'Response.Redirect("xxx.aspx"). I also defined a manifest file, Default.appcache as I want my application to work offline (in such case I javascript methods are used for redirection). Browser cached the page as expected but a problem occured - even though server is online, browser uses the cached page. When user enters Default.aspx no call is sent to server. How can I prevent this behavior? I would like the browser to send a normal request to IIS if it is online and use cached page only when server doesn't respond.
I would be grateful for all suggestions.
You can't, pages in the cache are always served from the cache. The only way to update them is update the manifest and force new versions to be downloaded.
If you want one page to be served when online and a different one when offline then you should investigate the FALLBACK section of the manifest. Note that the page which references the manifest is always cached, so you need to set the fallback up on a different pair of pages.
Related
We recently updated a Joomla site running on IIS, which has a menu item that opens an ASP.NET Framework 4.8 page in an iframe. This page opens on every browser I've tested on multiple machines. The problem is that since yesterday when the new site was deployed, some users are reporting a blank page when accessing the new menu item. In most cases, asking the user to clear their cache will allow them to view the page. Most of the problems were with Chrome browsers, but this is probably due to it being the most popular browser.
So I think there is a caching problem on the web site with the ASP.NET page. I suspect that the few users who are having problems never close the web browser on their machine (most are business users). Is there a way force pages to expire and reload in an ASP.NET page?
Thanks.
You could loop through all the cache items and delete them one by one:
foreach (System.Collections.DictionaryEntry entry in HttpContext.Current.Cache)
{
HttpContext.Current.Cache.Remove(string(entry.Key));
}
Syntax Correction for ASP.NET 4.5 C#
foreach (System.Collections.DictionaryEntry entry in HttpContext.Current.Cache){
HttpContext.Current.Cache.Remove((string)entry.Key);
}
To expire web content, you can use some iis feature like Client Cache or output cache.
Client Cache:
This element specifies cache-related HTTP headers that IIS 7 and later sends to Web clients, which control how Web clients and proxy servers will cache the content that IIS 7 and later returns.
to set you can follow the below steps:
Open the iis manager.
Select the site or application.
Select the HTTP Response Headers feature.
In the HTTP Response Headers pane, click Set Common Headers... from the Actions pane.
In the Set Common HTTP Response Headers dialog box, check the box to expire Web content, select the option to expire after a specific interval or at a specific time, and then click OK. You can set time of expiration.
For more detail about output cache and client cache you can refer below article:
Client Cache
IIS Output Caching
We have a Sitecore/Webforms based website that we'd like to run behind Akamai CDN however we're having an issue with ViewState MAC validation on our postbacks.
We've worked around this for most of the core forms on the site (by taking them out of the CDN cache and serving them direct for every user), but we're left with a simple form in the footer of every page that posts back to the server.
Currently we're seeing errors:
Validation of viewstate MAC failed.
I believe this is caused by the CDN caching the viewstate fields from the original request and these (obviously) not matching for other users.
As we are running this site on multiple servers, we already have the machinekey correctly configured (we've been able to use postBackUrl settings to post back to other pages/SSL instances/etc.) before we added Akamai.
As we're running Asp.NET 4.5.2 there's no way we can even attempt to disable viewstate MAC even if we thought it was a good idea.
Setting ViewStateMode=Disabled still leaves us with a tiny viewstate (presumably the MAC) which still causes problems.
Is there anyway we can remove the session dependence from the viewstate?
The basic steps we can use to replicate this:
Request page from Browser A - Akamai caches page.
Submit form from Browser A - Success!
Request page from Browser B - Akamai serves cached page.
Submit form from Browser B - ERROR!
Nope, Akamai CDN never caches POST requests. But its good idea to try adding the forms to do not cache list and try replicate the issue.
I'm building a web app that uses a lot of CSS3 and session storage. My goal is to deny users of older browsers by redirecting them to a "we don't support your browser" page. I'm thinking of using an http module that looks at the incoming request. In the client page I would encode a hidden field that contains the user agent version.
I want this to work for both regular aspx requests and ajax requests to asmx files. What would a good method to do this be?
You may use HttpRequest.Browser property to detects browser type in ASP.NET and have a look at article by Scott Mitchell - Performing Browser Detection Using ASP.NET.
I don't think you would need to encode anything onto the page. Create a module that detects the browser, or the version of javascript the browser supports (for example), using the Http.Browser capabilities.
My setup: ASP.NET 4.0 Web Site running on IIS 6.0.
I have a site with many landing pages with virtual URLs, all being served by a single physical landingpage.aspx file (via ASP.NET 4.0 Routing), in which I use the OutputCache directive, caching the page on the server for 24 hours.
Recently, I started to experience a problem that the __doPostBack JavaScript block was missing from some of the generated pages. There is a LinkButton in the page (inside a webusercontrol), so the JS block should be there, but sometimes it isn't. This is naturally leading to JS errors in the browser upon clicking the LinkButton.
My suspicion is that maybe on the first visit to a given URL handled by the above mentioned physical .aspx file it might have been a visit by a client (a browser or a search bot) which maybe was considered by ASP.NET as a down-level browser, and therefore the doPostBack was not output into the generated cached version of the page, and then this wrong cached version is served to all the subsequent visitors...? On the other hand, I'd say ASP.NET is smart enough to generate different cached version for different levels of browsers, isn't it?
Nevertheless, my question is: can I find the cached files that are served to the visitors somewhere on the server, and somehow check if my assumptions are correct? Also, I would like to disable this ASP.NET recognition of browsers altogether and serve the same content to every browser, just as it would serve to any modern browser.
Thanks a lot for any advice and help.
Answering my own question: Confirmed that the website was sending back HTML without __doPostBack() for unrecognized browsers. Adding ClientTarget="uplevel" to the # Page directive at the top of the .aspx page in question solved the problem and __doPostBack() block is now always present.
If we use an aspx page with a Caching Profile, the server caches images that are loaded with the aspx page. So if ten clients load the same image through the aspx page (same url), for one client the image is gotten out of the db, for the nine others it is cached.
When we use a HttpHandler, this doesn't happen. The image is always fetched from the database. We have tried all different settings without any success. (we have checked this link and have not been able to cache on server side).
I can't answer based on experience of using the caching profile, so I'm not sure if this helps.
Under the covers, ASP.NET WebForms are driven by HttpHandlers - written by MS (as you'd expect). When you write you own Http Handler you don't automatically get all the functionality that the System.Web.UI.PageHandlerFactory handler has (the one that by default looks after .aspx pages/requests) - you have to bring it in (or develop it) yourself.
Maybe this is the problem you have - maybe the Caching Profile capabilities are being leveraged by the aspx pages because the System.Web.UI.PageHandlerFactory is already "integrated" with it out of the box, where-as when you write your own they just aren't there (by default) - and hence the they don't work.