Focus the Request button when closing modal.

We’ll almost always be doing that — so let’s focus it and make it easy.
Split force request into 2, show indicator.

Force Request isn’t grandular enough — we’d like to invalidate the browser cache sometimes but leave the proxy cache in-place.

But we also need the have the ability to invalidate both of them.
Don’t include force-request as a query param.

This one took a bit of sideways-glancing to figure out — since we’re actually *changing the URL* of the asset by adding a querystring parameter, it doesn’t invalidate the browser’s cache if it adds the ?force_request=true parameter.

The results were goofy:

1. Request is made to server, and it is cached on the proxy and client.
2. Server response is changed.
3. Request is made from client, served by the cache (as expected).
4. Client cache is invalidated and ?force_request=true is sent. Proxy is correctly invalidated, and server responds with new response.
5. Request is made from client, and the original (not new) response is returned. This is because the new request is cached with the querystring, which we are no longer sending.
6. Client cache is invalidated, proxy responds with cached new response (as it should — it’s operating correctly).
7. Client cache is now correctly updated.

Silly!

Instead of using ?force_request=true to indicate the proxy to invalidate itself, we can send it as a request header — leaving the URL intact and the normal caching behavior is restored.