IIS seems to be an application that listens for incoming connections, parses the data sent there as HTTP requests, and maps request urls to directories based on a site an application and a virtual directory, and then does something based on the file present (or not present) on that location.
MVC meanwhile takes an HTTP request, routes it to a controller, which generates a HTTP response and sends it back.
It seems MVC handles exactly the same part of the network stack as IIS does, modulo the network endpoint (and that is a fairly trivial part of code, the hard work is done by the underlying OS part of the network stack on TCP level), but an MVC site is hosted "in" IIS somehow.
But IIS is a massive program. It must do something other than connection management. What does it actually do, and what do all these concepts ("site", "application", "virtual directory") mean in the context of a project that seems to replace their function in the first place?
MVC nor IIS do any port listening or HTTP parsing. That's http.sys's job, which is the HTTP Server API. See MSDN: HTTP Server API, how exactly does http.sys work, Introduction to IIS Architectures, and especially HTTP Request Processing in IIS.
IIS adds a lot of functionality on top of http.sys, apart from configuration and management: handlers and modules. Those allow you to run any kind of code to generate or alter a response for an HTTP request.
Key point here are handlers. They decide what particular piece of software will be invoked to handle a request, or they handle the request themselves. You have static resource handlers to handle for example requests for image, css and js files. There's also the ASP.NET handler that handles .aspx requests, see Introduction to HTTP Handlers.
Now MVC works hand in hand with a routing handler. All that the MVC handler does is look at the URL and your routing configuration, and then choose which controller method to invoke to generate the response for the request.
Related
I have defined a location for the page in the xml
<error-page>
<error-code>404</error-code>
<location>/faces/public/error-page-not-found.xhtml</location>
</error-page>
<error-page>
but I want the URL to be like below:
faces/{variable}/public/error-page-not-found.xhtml
where the value of the variable will change according to different situations
This question is a bit subjective though in general HTTP errors are handled by the server and most of the time by the scripting language on the server (and occasionally the HTTP server software directly).
In example the Apache HTTP web server software allows for rewrites. So you can request a page at example.com/123 though there is no "123" file there. In the code that would determine if you would have something that would be available for that request you would also determine if a resource exists for that request; if not then your server scripting code (PHP, ColdFusion, Perl, ASP.NET, etc) would need to return an HTTP 404. The server code would then have a small snippet that you would put in to the body of the code such as the code you have above.
You would not need to redirect to an error page, you would simply respond with the HTTP 404 response and any XML you'd use to notify the visitor that there is nothing there. HTTP server software such as Apache can't really produce code (it can only reference or rewrite some file to be used for certain requests).
Generally speaking if you have a website that uses a database you'd do the following...
Parse the URL requested so you can determine what the visitor requested.
Determine if a resource should be retrieved for that request (e.g. make a query to the database).
Once you know whether a resource is available or not you then either show the resource (e.g. a member's profile) or server the HTTP status (401: not signed in at all, 403:, signed in though not authorized where no increase in privileges will grant permission, 404: not found, etc) and display the corresponding content.
I would highly recommend that you read about Apache rewrites and PHP, especially it's $_SERVER array (e.g. <?php print_r($_SERVER);?>). You'd use Apache to rewrite all requests to a file so even if they request /1, /a, /about, /contact/, etc they all get processed by a single PHP file where you first determine what the requested URL is. There are tons of questions here and elsewhere on the web that will help you really get a good quick jump start on handling all that such as this: Redirect all traffic to index.php using mod_rewrite. If you do not know how to setup a local HTTP web server I highly recommend looking in to XAMPP, it's what I started out with years ago. Good luck!
I'm working on a project to require HTTPS everywhere among a suite of MVC and WebAPI applications. I'm trying to understand the trade-offs between clicking the "Require SSL" checkbox in IIS & using a URL Rewrite zmodule vs. using a RequireHttpsAttribute in my global filters and modifying my web.config.
I've found the following guides detailing each approach:
https://webmasters.stackexchange.com/questions/28057/iis-7-require-ssl-automatically-redirect-to-https
http://tech.trailmax.info/2014/02/implemnting-https-everywhere-in-asp-net-mvc-application/
Explain the mechanism can be lengthy, so I will just list the most significant differences in behaviour:
do "Require SSL" in IIS:
The context basically expalin what it do, it's "Require" not "Enforce", which means, if people trying to access your website content through http, the server will just respond with a 403 error, which is usually not a desired behavior, but this may help some certain situation
using URL rewrite module:
The module itself can do quite some different thing, but I assume you are just going to do the regular https redirect. Which means, if user trying to hit ANY content of the site through http, the server will do a 301 or 302 redirect to the https version of same url. This is usually a good option since it doesn't affect any usability of the website.
Global RequireHttpsAttribute action filter: This do similar thing to option number 2, it will do a 302 redirect for any http request that is hitting an ACTION. The main difference is that this only applies to all actions in your controllers, Which means, if someone trying to just get a image or css file through http on your website, this option will let it through and not do any enforcement. This leave you the capability to serve static contents through http, which can be useful in some specific circumstances
Just one extra thing worth mention, the 301 and 302 redirect is not going too well with http POST, so if your user trying to do a post through http, the request body will get lost (thanks to the info from #ChrisPratt).
Typically the folks managing the infrastructure are responsible for making sure things are on https. Typically they aren't very good at this so that is where the RequireHttpsAttribute kicks in as it can encforce https requests at a code level thereby enforcing the HTTPS-only attribute.
In practice it isn't so great as many production setups -- including stackoverflow.com's -- see https terminated in an edge device before being unwrapped and handed to the back-end apps as http and the require https attribute isn't quite nuanced enough to understand this distinction.
The best bet in general is to configure the edge device providing the public http interface to take HTTPS and only HTTPS. Then setup secondary virtual sites [or whatever is vendor appropriate] to redirect all traffic to the cannonical HTTPS url. I'd be a bit nervous about relying upon the RequireHttpsAttribute unless it will be a small app handling it's own requests. That still leaves open holes in terms of artifacts and other things that might not be coming off of a controller.
I am trying to implement the Jonathon Kresner
"Asp .net Mvc 4 Proxy Server/Controller (For help with Cross Domain Request)" https://gist.github.com/jkresner/3982746 .
Could anyone indicate how to call it from jquery please?
the coffescript call with the article gist.github.com/jkresner, leaves me perplexed.
The coffeescript basicaly says that for clients who can't connect to the remote url by themselves, swap out the specified remote URL reference (i.e. http://api.othersite.com/Widget/7 ) with a reference to http://myoriginalpagehost.com/proxy and let the server side proxy the content from the http://myoriginalpagehost.com/proxy URI over to the http://api.othersite.com/Widget/7 URL.
One thing to note on that proxy is that it appears that cache control mechanisms will likely be subverted causing a potentially significant system load. Something to think about before boilerplate copy / paste of someones code. :-/
This article discusses another solution to the proxy issue that makes use of IIS's URL rewriting mechanisms. No coding, just configuring.
There is a SharePoint farm with aroubd 5 web apps. Each web app has numerous site collections and within each site collection there are numerous sites.
Some of the sites in each site collection will on longer be used and when any request comes to the site collection, it needs to be routed to a new SharePoint Url in a different farm.
I am trying to implement a http handler or http module to catch the requests that need to be directed and redirect to new url.
However, i need to know:
Is going with Http Handler or Http Module approach the best? The client cant afford to have some custom webparts on home pages of each site collection to redirect. Therefore the request needs to be redirected before it comes to the page. Therefore i am assuming a Http Handler or Module is best way.
What to choose between a Http Handler and a Http Module. I have noticed that
a> if i go with Http Module, it is executed on every request to the web application. For instance, if i just type the Url of a site collection in the browser, the Http Module gets executed around 10 times. Will this not be a performance issue?
b> if i go with a Http Handler(to handle *.aspx), handler class is invoked just once per request but once the code is getting executed, if it is found that no Url redirection is required then i am not getting any html on the page. I guess this is expected as Http Handler will be responsible to generate the response (html) and since the request is handled by the custom handler and since no code is written to generate the html, nothing is diplayed on the page.
Please let me know your thoughts.
Thanks,
Faiz
Using a Java based image uploader and having problems, seems my controller action is not being hit if I upload multiple files. I can't use fiddler or FireBug because they don't pickup the Java apps request to the server. I need to see what is being requested in debug mode so I can fix my Route - I am assuming this is my problem.
How can I hook into this and see what the request is?
You could still use a web debugging proxy (like Fiddler) if your Java based image uploader supports a proxy. Other than that you can use a packet sniffer like Wireshark or break your debug session at a point with a HttpContext, e.g. in Global.asax at BeginRequest.