HttpPatch action filter attribute confirm that specified method should be available only via HTTP PATCH request. HttpPatch action filter is new in MVC 4. HTTP PATCH verb is relatively new and it is used to modify an existing HTTP resource. HTTP PUT allow us to create or replace existing HTTP resource but we cant modify existing resource with HTTP PUT. This is where HTTP PATCH comes in picture.
HttpOptions action filter specifies that, user should access this action method via HTTP OPTIONS request. Trying to access other than HTTP OPTIONS verb will fail and result in HTTP 404 not found error. This action filter is new in MVC 4. With HTTP OPTIONS verb client can determine the capabilities of the server.
HttpHead action filter specifies that, this action method should be only accessible via HTTP HEAD request. HttpHead action filter is new in MVC 4. HTTP HEAD request is similar to GET request but it instruct server to send only response header, and not whole response body.
ActionName action filter allow us to change name of action method while we are accessing it via url. By default we can access action method with {controller}/{action} pattern but in some case we don’t want action method to be accessible by its name. So in such case we can use ActionName action filter attribute.
In this ASP.NET MVC action filter tutorial series, HttpPut is 4th attribute which allow developer to restrict action method access based on HTTP verb. As name suggest, HttpPut marked action method will be accessible only via HTTP PUT verb. Similar to HttpPost, HttpGet & HttpDelete, HttpPut also inherited from ActionMethodSelectorAttribute.
HttpGet action method selector attribute restrict action method so that marked action method would be served for only HTTP GET verb. Similar to HttpPost, HttpGet also inherited from ActionMethodSelectorAttribute.
In ASP.NET MVC, every public method of controller is accessible via url regardless of return type, so if we have created any public method in controller which is not intended to serve as action method then also it is accessible via url. One solution is that keep this method as private or protected but some time we need to keep this method as public. This is where NonAction attribute comes in picture. First have a look at public method in following code.
As name suggests, RequireHttps attribute indicate that this action method should only accessible by SSL or HTTPS. Whenever action methods are marked with RequireHttps, at that time we cannot browse it with HTTP protocol. If we try to browse it with HTTP then it will be redirected to HTTPS url. We can also use this attribute at controller level.
In ASP.NET MVC controller, HttpPost action method selector attribute let us restrict action method so that specified action method is only accessible via HTTP POST verb or request. HttpPost is inherited from ActionMethodSelectorAttribute which is used to validate action method selection based on controller context.
Earlier almost year ago, when MVC 4 developer preview version released at that time I have blogged on how to create custom transform type for bundling in ASP.NET 4.5 & MVC 4. There are some changes in System.Web.Optimization since developer preview release to RC. As far as this post concerns, I am more interested in changes in IBundleTransform interface so I am rewriting old post which include changes in IBundleTransform.
Web optimization frameworks include two defaults transform type JsMinify and CssMinify which is used by ScriptBundle and StyleBundle respectively. However we can create our own custom transform type to processe references as per our need. To create custom transform type, we need to create class which implements IBundleTransform interface.
Last week, one reader of this blog asked, how to setup cookieless domain to serve bundle response and other static resources in ASP.NET application. Yes it is very much necessary and one of the web performance guideline that static resource should be served from cookieless domain for better performance. So here in this post we will see how to setup ASP.NET application and IIS for cookieless domain with minimal code changes and deployment task. You can directly jump to IIS setup section if you don't want to read detailed information.
In the last post, we have seen how we can use PreApplicationStartMethod assembly level attribute to configure ASP.NET application at runtime. Taking it further, in this post we will see how to leverage PreApplicationStartMethod to register HTTP module dynamically at runtime. You can read more on PreApplicationStartMethod in this post here.
First of all we need to install/reference Microsoft.Web.Infrastructure assembly which provide API for registering HTTP module dynamically. To install Microsoft.Web.Infrastructure, type following in the Package Manager Console.
Few days back when I was exploring how ASP.NET 4.5 and MVC 4 bundling are implemented specially how bundle url are resolved at runtime. At that time I found that PreApplicationStartMethod is used to hookup bundle url. PreApplicationStartMethod is used to configure ASP.NET application at runtime. PreApplicationStartMethod is fired in early stage of application startup and hence it is executed before Application_Start event so we can’t get reference of HttpApplication or HttpContext from within PreApplicationStartMethod. To create Pre application start method, we need to create a class with static method and then after we have to hookup that method through PreApplicationStartMethod attribute.
