I'd like to propose that Javascript authors gain access to the request and response headers tied to the current web page, perhaps via window.headers.request/window.headers/response, or a function along the lines of what XHR has. There are two reasons for this: 1) It has become more common for developers to send custom headers with web pages containing metadata (how the request was handled, how to use the document, etc.) which cannot necessarily be deduced by the document content itself. These headers could influence the operation of client-side javascript applications if they were able to read them. 2) While bug 30862 is about making revalidation sticky for lazy-loaded resources up until onload for the main document fires, Javascript developers may want to force revalidation of a particular resource or set of resources *after* the onload event. It will be possible to manually expire resources when bug 51286 (cache not being cleared by no-cache XHR) is fixed. However, a primary reason a developer would decide to force revalidation on a set of resources in their application would be because the main page was refreshed and the resources in question were not able to be revalidated before unload. Example: Suppose an end user hits refresh to reset the Javascript application. The onload event for the page fires. Now the user clicks a button to access a new area of the application for which additional scripts need to load in. Those scripts should only load after user interaction, because we don't want to load all possible scripts for the entire application up front. Now the developer is stuck because she cannot detect that the main page was refreshed and then decide to revalidate the additional scripts upon the user's first click to access this part of the application. For both these reasons, being able to know more about the main document's headers would empower Javascript developers to make these sorts of decisions as needed.