Develop Reference

Where to cache in ASP.net MVC 5 server or client

I am going through a tutorial in ASP.Net MVC 5 and I learned about caching. But I could not understand what determines whether I should cache at client or server.
Here is the code snippet.
For client:
[OutputCache(Duration = 86400, Location = OutputCacheLocation.Client)]
public ActionResult SelectLocation()
{
}
For server:
[OutputCache(Duration = 86400, Location = OutputCacheLocation.Server)]
public ActionResult SelectLocation()
{
}
Question: Can someone tell me when I should apply client caching and when should I use the server one. And the downside or any consequences I should look for?

In regards to OutputCache, "client" caching simply means that cache-control headers and/or an expires header will be sent with the response, indicating that the client may cache the document. Typically, the client, especially if it's a web browser, will choose to do so. It then will not need to make a new request if the same resource is needed again. However, the browser may still occasionally make a HEAD request just to check if there's a new version of the resource.
"Server" caching means, still in regards to OutputCache, that the server will cache the response locally, usually in memory. This means that as long as the cache is still valid, the server will not actually render the action again, but rather, will just serve up the cached resource, instead.
The main difference, then, between the two is that the server cache will be used for all requests for that resource, regardless of what client is currently making the request, while client cache will obviously just be limited to that one particular client. The server will not need to render the action again for that client, but will for the next client that comes along.
However, the default is Any, which includes server and client caching (as well as other locations). In other words, server and client caching are not mutually exclusive, and usually you'd do both to minimize both the work the server needs to do and the amount of requests it needs to respond to.

Have a look here. It is very nicely explained
By default, content is cached in three locations: the web server, any proxy servers, and the user's browser. You can control the content's cached location by changing the location parameter. When you cache on the server, every user receives the same content and when it is only client side, the cached content differs by users.
The location parameter has the default value Any which is appropriate for most the scenarios. But some times there are scenarios when you required more control over the cached data.
Suppose you want to cache the logged in use information then you should cached the data on client browser since this data is specific to a user. If you will cached this data on the server, all the user will see the same information that is wrong.
You should cache the data on the server which is common to all the users and is sensitive.

One point of view could by the cache invalidation scenario. When caching on the client side, you'd need to adjust the URL the client hits to avoid cache hit / force recalculation of response. When caching on the server side, you might invalidate the cached content easier. See this question: How to programmatically clear outputcache for controller action method

As described in https://msdn.microsoft.com/en-us/library/system.web.ui.outputcachelocation(v=vs.110).aspx
Client will instruct browser to cache html in it's own cache.
Pros: faster since it is cached on browser, does not take up server memory.
Cons: it is dependable on user browser settings (cache size, expiration etc.) and user can delete on it's own
Server will keep cached html on server
Pros: does not depend on browser rules since it sends no-cache, you control the cache, not user.
Cons: slower then client since it will always include transport, takes up server memory

The reason that there are a variety of options when dealing with cache control is simple; there is no universal correct answer that is applicable to all sites.
A "business card" site that is pretty static in it's design and content as well as being the only site on the server could pretty much be set to cache it everywhere for an infinite time period. However, if that server is actually hosting a thousand sites then we start have to worry about the server cache and its viability because IIS will start dumping cache items if the memory gets low, so we may not want that server cache.
If we have an ecomm site that is very high traffic with product changes and additions on an hourly basis, we would want to reduce the max-age so that the content remains up to date. But then again, the content generation for these more demanding applications can slow the server down due to all of the dynamic content processing, especially if this site is on a shared server.
There are plenty of resources on the general internet, MSDN, and here that you can review to help you determine on what is best for you. With the wide variety of sites that I have worked with in single and shared environments I have most as Server and client locations, some will use the Last-Modified header and others use eTag.

Entire website to migrate from Http to Https

This seems like a duplicate question - but after hours of search, it seems there is no clear question-answer which summarize the issues i'm raising here.
We have a web application (built using asp.net MVC4) which stores customers sensitive customer information.
We've decided to migrate our entire application to https.
My question is, except for the IIS and certificates technical issues, which we've already know how to deal with, what should be changed on code level?
What will happen for instance for:
Included external scripts containing http, such as: http://code.jquery.com/jquery-1.7.1.min.js - will it work automatically without any problem and popup messages or blocking on the client browsers?
Internal links, which we've forgotten to change, which redirect to our site using http?
Images/Sources which have http in their URL.
Should we change all references from http to relative, or just specifying // without the http/https protocol ? (as seen on other posts on this subject)
Should we do nothing, will it happen automatically?
Is there a way to do something in IIS or Global.asax etc, in order to automatically take care of all http leftovers?
What else should we take in account when migrating to https?
Thanks in advance.

For all internal static resources hopefully you have used #Url.Content helper and for all internal dynamic resources you have used #Html.ActionLink, #Html.BeginForm, ... helpers to generate the links. This way you don't need to worry about anything.
For all external resources you could use // syntax in the link which will respect the protocol.
Since you are switching to HTTPS you might consider marking all your cookies (if any) with the secure flag to ensure that they are transmitted only over a secure channel.

prevent log on to web application by programming

I am working on a web application which provide some services for its users who has accounts to log on to the web application. as you already probably know, it is possible to programmatically log in to web sites by providing username and password and sometime a catcha code. As I know it is possible to simulate the request programmatically. for example in c# we can make a request and fill all request headers such as User-Agent, Referer, .. and send it to the server in order to log in.
However, my question is how can I prevent users from logging in into web application via something other than browsers?
Thanks.

You can't. Timing, CAPTCHA and honeypot fields and using Javascript are common ways to prevent most robots, but someone dedicated to specifically targeting your site will find a way to simulate a genuine user.

All you can do it raise the barrier as high as you are able, and as high as is acceptable for your users. Security is always a trade-off against convenience.
There are ways you can raise the barrier, but each method's application varies across applications. For example, you could sniff the user agent and check it against a list and reject anything that isn't defined as a browser on your list. That kind of thing works for me in an internal situation where we have specific policies and controls over the browsers employees can use. For a web application however it would likely fail as the list would need to be managed, and people in the outside world probably know how to spoof their user agent anyway.
So it all depends. You need to consider the vectors around where your threats are coming from and guard against those threats as best you can rather than trying a blanket approach.

Caching application data in memory: MVC Web API

I am writing an MVC webAPI that will be used to return values that will be bound to dropdown boxes or used as type-ahead textbox results on a website, and I want to cache values in memory so that I do not need to perform database requests every time the API is hit.
I am going to use the MemoryCache class and I know I can populate the cache when the first request comes in but I don't want the first request to the API to be slower than others. My question is: Is there a way for me to automatically populate the cache when the WebAPI first starts? I see there is an "App_Start" folder, maybe I just throw something in here?
After the initial population, I will probably run an hourly/daily request to update the cache as required.
MemoryCache:
http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx
UDPATE
Ela's answer below did the trick, basically I just needed to look at the abilities of Global.asax.
Thanks for the quick help here, this has spun up a separate question for me about the pros/cons of different caching types.
Pros/Cons of different ASP.NET Caching Options

You can use the global.asax appplication start method to initialize resources.
Resources which will be used application wide basically.
The following link should help you to find more information:
http://www.asp.net/web-forms/tutorials/data-access/caching-data/caching-data-at-application-startup-cs
Hint:
If you use in process caching (which is usually the case if you cache something within the web context / thread), keep in mind that your web application is controlled by IIS.
The standard IIS configuration will shut down your web application after 20 minutes if no user requests have to be served.
This means, that any resources you have in memory, will be freed.
After this happens, the next time a user accesses your web application, the global asax, application start will be excecuted again, because IIS reinitializes your web application.
If you want to prevent this behaviour, you either configure the application pool idle timeout to not time out after 20minutes. Or you use a different cache strategy (persistent cache, distributed cache...).
To configure IIS for this, here you can find more information:
http://brad.kingsleyblog.com/IIS7-Application-Pool-Idle-Time-out-Settings/

Caching Proxy Design Advice

I'm relatively new to proxies.
I am currently required to design a caching proxy for work.
We have a webservice which serves up data based on calls to it, naturally.
I am required to create a proxy for a rich client application that caches the results of these calls.
The results are basically string names of products identified by a composition of ids.
I could just create a class that acts as my proxy client that caches the results in a cache, I was thinking of using the System.Web.Caching.Cache object.
However I thought I'd ask to see if there are any design aspects and considerations that I have missed. Is there a design that is commonly known that I have not found?
[UPDATE - 12 Oct 2009]
Seems like System.Web.Caching.Cache is not advisable for client side caching.
http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx:
The Cache class is not intended for
use outside of ASP.NET applications.
It was designed and tested for use in
ASP.NET to provide caching for Web
applications. In other types of
applications, such as console
applications or Windows Forms
applications, ASP.NET caching might
not work correctly.

First, I've used System.Web.Caching.Cache in Winforms and Service solutions and never had a problem with it. I recommend mitigating against the disclaimer by testing to ensure the cache works and doesn't leak resources, but none of my testing ever showed this happening.
Alternatively there is a caching solution in Enterprise Library, and probably a bunch of other open source ones you could consider. And there are probably some commercially supported ones too if you prefer.
However, are you hosting your web service in ASP.Net (.asmx extension is usually a good indicator). In that case your still in ASP.Net and so the disclaimer shouldn't apply.
Also note that ASP.Net has caching options you can drive directly from the web.config without having to do any coding.
But all of the above is server side caching.
Assuming your web service is using HTTP (or HTTPS) as the transport layer, then proxy and client caching require use of the HTTP response headers, I think Cache-Control, Expires and possibly Last-Modified are involved. Then it is up to the client and proxies to decide whether they will support caching or not.
Alternatively if your actually trying to write a proxy solution that supports caching (and that would be rewriting a wheel so you should have a good reason to do this) then you probably want a HTTP Handler, with the System.Web.HttpRequest and System.Web.HttpResponse representing the client side of things, and passing the request through to the server using System.Net.HttpWebRequest and System.Net.HttpResponse. The System.Web.Caching.Cache could then support your cached responses on your proxy. That said there would be lots of rules to have to implement here, including HTTP Request headers (also has Cache-Control options).