MVC4 Bundling：包含bundle的URL的位置

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.