MVC4 binding: where is the url for the package

Question

When a packet is registered in MVC4, what is responsible for "intercepting" incoming http requests for /bundles/someBundle?v=1hDzBpmYJm4Iu-OjRN1YqS1WeNThVl0kStLJGP8WCr41 ? also, since the hash for each packet is only calculated once (on the first request), where it is actually held - and is it possible to return 404 if the incoming hash does not match

Answer 1

which is responsible for "intercepting" incoming HTTP requests for ~ / bundles / someBundle

There are no incoming requests in ~/bundles/someBundle . This is the server assistant you use ( Scripts.Render ), which on the server (within the same HTTP requests) interprets this value and inserts the correct URL into it.

also, since the hash for each bundle is calculated only once (on the first request), where it really is held,

The actual contents of the package are stored in a server-side cache: HttpContext.Cache . The actual hash represents the SHA256 hash for this content, which is calculated every time you use the Scripts.Render .

---

UPDATE:

This is System.Web.Optimization.BundleModule , which is automatically registered when you reference the System.Web.Optimization assembly, which is responsible for intercepting requests for URLs like /bundles/someBundle?v=1hDzBpmYJm4Iu-OjRN1YqS1WeNThVl0kStLJGP8WCr41 and return the actual content.

Answer 2

You must have the BundleConfig.cs file in the App_Start folder in your web project.

This section basically associates the URL "/ bundles / something" with some script (s). When accessing the site in Release mode (no debugging is activated), it automatically combines the script into one file in memory, minimizes the script, adds caching headers to the request, and generates a hash of the file contents.

If you are in debugging, all scripts should be separated to facilitate debugging.

You either redefine the packages that you see in this file, or you declare some of your own.

Enjoy.

Answer 3

The reason for adding a query string with a parameter based on the contents of the actual files you are servicing is the solution to the cache problem. In addition, you can tell browsers to cache these requests over a long period of time and speed up subsequent page loads.
Therefore, for the developers of this binding mechanism, there is no difference in what this parameter is. The only important thing is that if you change the contents of your scripts or css-hash changes, this will cause the client browser to request new files from the server.
As for what is responsible for the intersection of these requests, there is the MVC source code available on codeplex, but I assume that it connects directly to the routing.