[whatwg] Access the Response Headers for the Current Document

[Joseph Pecoraro]

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.