I am developing a website and I want to implement caching to improve its performance.
If I use
<# OutputCache Duration="20" VaryByParam="None">
where will my page be stored? On the client side or on the server? If it's stored on the client side, where is it stored?
Can I cache a master page?
If you don't specify a location, the Output Cache directive will at least store it on the server. It also allows (via headers) intermediate proxies and clients to cache if they choose to.*
It's up to the consuming client to a) choose whether to respect the cache header and b) where to cache. For most browsers it's usually in "Temporary Internet Files" or some equivalent.
*It's more of a "suggestion" that proxies or clients cache, since either way it's ultimately up to them.
You may checkout the documentation. According to it the default value of the cache location is Any which means:
The output cache can be located on the
browser client (where the request
originated), on a proxy server (or any
other server) participating in the
request, or on the server where the
request was processed. This value
corresponds to the
HttpCacheability.Public enumeration
value
As far as caching the master you cannot put an OutputCache directive to a master page. You could do it programatically by enabling caching in all the content pages.
Related
I want to be stored some master data in web server Cache and that data should not be expired. Consider a master data like type of users -> Trader, Supplier, Producer and so on. So this type of master data is usually less intensive to add/delete/update. Now in a normal scenario the process of querying the database for each request is not cost-effective in terms of server resources, hence it is much better to cache or persist the data. So in this case what type of expiration cache need to be used? Is there any option in cache to persist the data alive in webserver until iisreset/recycle?
gayathri, you can explicitly save the value in cache like below:
Cache["UserType"]="Trader";//or any runtime value
Regards,
Aamir
When the bundle is registered in MVC4, what is responsible for "intercepting" incoming http requests for /bundles/someBundle?v=1hDzBpmYJm4Iu-OjRN1YqS1WeNThVl0kStLJGP8WCr41?
also since hash for each bundle is calculated only once (at a first request), where is that actually held, - and is it possible to return 404 if an incoming hash does not match
what is responsible for "intercepting" incoming http requests for ~/bundles/someBundle
There are no incoming requests to ~/bundles/someBundle. It's the server side helper that you are using (Scripts.Render) that on the server (within the same HTTP requests) interprets this value and spits the correct url in the resulting HTML.
also since hash for each bundle is calculated only once (at a first request), where is that actually held,
The actual bundle contents is stored in the server side cache : HttpContext.Cache. The actual hash represents a SHA256 hash on this content that is calculated every time you use the Scripts.Render helper.
UPDATE:
It's the System.Web.Optimization.BundleModule that is auto-registered when you reference the System.Web.Optimization assembly that is responsible for intercepting requests to urls like /bundles/someBundle?v=1hDzBpmYJm4Iu-OjRN1YqS1WeNThVl0kStLJGP8WCr41 and returning the actual contents.
You should have a file called BundleConfig.cs in a folder App_Start in your web project.
That section basically links a url "/bundles/something" to some script(s). When in accessing the site in Release mode (not debug activated), it will automatically merge the script into one in-memory file, minimize the script, add caching headers to the request and generate a hash of the file content.
If you are in debug, all the scripts should be separated to make debugging easier.
You either redefine the bundles you see in that file or declare some of your own.
Enjoy.
The reason to append a query string with a parameter based on contents of actual files that you are serving is solving the caching problem. Sou you can inform browsers to cache this requests for a long period of time and speed up subsequent pages load times.
So for developers of this bundling mechanism there is no difference what that parameter is. Only thing that is important is that if you change contents of your scripts or css - hash would change and it will force clients browser to request new files from the server.
As for what is responsible for intersepting this requests - there is source code of MVC available on codeplex, but i guess it plugs right into routing.
I am developing an iframe for use on a number of our partners websites.
Is there any way I can make sure it can only be used on those websites and not by anyone else
I was intending to add a compulsory querystring to the URL for the website.
Each partner would have a different value in the quesrystring dnd use that to look up an allowed domain
However, is there anyway to know the top level domain of the site hosting the iframe?
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
Or do you need to send the domain from javascript?
Any advice?
However, is there anyway to know the top level domain of the site hosting the iframe?
Nothing reliable.
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
It might be sent in the referer
Or do you need to send the domain from javascript?
If you want to fetch it from the framed page, you will be blocked by the same origin policy.
If you want to sent it from the framing page, you will be putting it in the query string and you can't trust it because it can be set to whatever the person writing the framing page likes.
There is also the X-Frame-Options header (but that has limited browser support).
The most reliable solution I can think of is:
Require the origin to be specified in the query string used to load the frame
Check the referer. If it doesn't match your white-list and is not blank, redirect to a page that is blank except for a link to your site with target="_top" and some JavaScript that top.location = "your site"
Check that the origin specified in the query string is on your whitelist, if it isn't act in the same way as a rejected step 2
Output an X-Frame-Options header that limits the framing to the specified origin
That is likely to catch enough browsers to discourage the framing site from framing your site.
You can try to check referrer which normal browser will send for IFrame requests on the page.
You also can use "x-frame-options" header covered in (How to Block Iframe call and MDN ) but not every browser will respect that (on other hand it is more reliable if browser supports it).
iframe's sanbox attribute might be helpful in controlling the various security aspects in an iframe including origins
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
The Architecture Journal of 2007 has a nice article about this: Secure Cross-Domain Communication in the Browser
Basically what the article suggests is:
If you have page A on domain 1 with an iframe with page B on domain 2 as its source , then having an iframe on page B to page C on domain 1, would allow you to pass information across domains
I haven't tested it, but this sounds like it could work.
Another possibility is create a file with a special filename (for instance a hash of the URL of page B on domain 2) and basic extension (like .htm) and place it in the root of domain 1. Checking whether the file exists on domain 1 cannot be done by javascript however, so it should be done with server side code.
I need to know where the files are saved when a page is cached using the following:
<%# OutputCache Duration="60" VaryByParam="None" %>
Because sometimes I need to delete the files to 'reset' the page so I can get the latest data.
EDIT: A second question: does the above line uses the memory of the server to save the cached pages?
Thanks
You could use the RemoveOutputCacheItem method to remove a cached page.
does the above line uses the memory of the server to save the cached pages?
This will depend on the value of the Location attribute. If you set it to Server then it will be stored in memory. If you set it to Client, then the page will be cached on the client browser.
I'm pretty basic with .net
But basically I've been told that to have session stickiness for my website in the environment it is to be deployed means I have to get session from the cookie ASP.NET_SessionId
But what does this mean/how do I use this?
And where I am using my existing session code e.g. Session.Add("Something", something) do I now need to change this?
This is automated for you
You don't have to manually read cookies yourself. Asp.net does it for you. So whenever you access Session dictionary your session will already be preserved if it existed from your previous request(s). If there is none (or expired) it will also be automatically created so adding items to it will make it work without a problem.
So basically instead of accessing Session identifier from a cookies and do whatever with it (as you won't be able to access intrinsic session store), just use Session:
Session["SomeKey"] = myVar;
// or
Session.Add("SomeKey", myVar);
and for reading
var o = Session["SomeKey"];
Are cookies mandatory?
Basically Asp.net supports other means of session ID storage apart from cookies. You can enable cookieless session if you wanted to (a setting in web.config file). Session identifier will be added to your URL like:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
Read more about it here on MSDN.
What's the default?
By default session identifier is preserved in cookies. That means that you don't have to change anything in web.config. But if you'd like to use other means you'd have to set that in web.config (check the same upper link as before).
Typically the way that I use session variables in ASP.NET is like this
// set
Session["SessionVariableName"] = localVariable;
// get
localVariable = Session["SessionVariableName"] as LocalType; // then check nulls
The issue with any sessions is that if you don't go out of your way to change it, the default stores sessions in-proc so every time IIS recycles a worker process your session is lost. This can be easily fixed by using the built-in ASP.NET State Service. A quick search turned up this article on using it.
You can get a reference to the current session in multiple ways but the most easy way is just use the session property on the page.
See:
http://msdn.microsoft.com/en-us/library/system.web.ui.page.session.aspx
Session stickiness is not a feature of ASP.net, but rather of a load balancer that may sit in front of it. If you are using InProc sessions, then the session data is stored in the server's memory. With "sticky" sessions, the load balancer will send all requests from the same source (based on IP usually) to the same server to ensure that the session always exists.
This isn't the most scalable way to handle a web farm scenario. Microsoft introduced two other mechanisms, StateServer and SqlServer which serve to send the session data to a single location for all web front ends.
You likely just need to make sure you don't have cookieless set to true in your configuration.
Regardless of how this is all configured, you will always retrieve your session data the same way - ASP.NET abstracts the details away.
// Set
Session["mySession"] = "Hello World";
// Get
var s = Session["mySession"];