- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Tue, 28 Jul 2009 22:39:39 -0400
On Jul 28, 2009, at 9: 21PM, Ian Hickson wrote: >> Use Cases: >> Any that apply to XHR accessing their response headers would >> certainly >> apply here. Some thoughts are accessing the Content-Type header or >> Custom Headers and acting accordingly. > > You can just include the data straight into the page, for now. It's > really > clear what the use cases would actually be in practice. True, but that feels like a hack. If the HTTP protocol contains the data you need, then a server-side script may try to provide the data and may possibly provide an incorrect value. Likewise at the very least its a duplication of data being sent. This is certainly better then the current method, but not optimal. >> Come up with a clear description of the problem that needs to be >> solved: >> Cannot access the Response Headers for the current document in >> Javascript. >> >> Any there Browser Implementors out there that agree with this? If >> so, >> any thoughts on the best ways to expose the current page's request >> headers to Javascript? Certainly they are readonly, modifying them >> seems to be useless. How about keeping consistent with the XHR >> interface >> with something like: >> >> document.getAllResponseHeaders() and >> document.getResponseHeader(header) > > This is something that might make sense for a future version, but in > the > absence of a compelling need for this, I'm going to skip adding this > in > this version. I originally helped someone in an IRC channel with this question. He wanted to check a "Date" header being sent from his server, via Javascript. I don't know what his exact reason was. We provided him the same solutions mentioned here. However, like Adam de Boor suggested, a use case could be detecting proxies. The use case that I thought of was using custom headers to ensure requests go to a certain server in a cluster, perhaps to maintain a session with a reasonable cache. But that isn't really compelling and probably not very common.
Received on Tuesday, 28 July 2009 19:39:39 UTC