Re: Headers / caches proposal (revised)

On 2006/05/02, at 6:54 PM, Maciej Stachowiak wrote:
>>
>> WRT Connection: Mark Baker made an argument that someone may  
>> design an extension that is hop-by-hop, and therefore needs to be  
>> added to Connection. Note that the proposal doesn't allow it to be  
>> overwritten; only appended to.
>
> My previous justification for why this should be disallowed:
>
> * Connection (2, 3) - could break other requests on same persistent
> connection; MUST be 'close' in UAs that don't support persistent
> connections.
>
> Where 2 and 3 are:
>
> 2) It would allow a client to cause the UA to violate the http RFC
> (besides just requirements on syntax, obviously those are possible
> with any header).

By making an end-to-end header hop-by-hop? E.g.,

Connection: Host

I agree it could mess things up; I think the question is whether this  
is a security problem, or a "doctor, it hurts when I do this!" problem.

> 3) It could seriously interfere with correct operation of the network
> layer (specifically, it could break in-progress or future requests,
> or cause improper responses to be added to the cache.

One compromise could be to disallow Connection from having any of the  
author-prohibited headers from being added to it. Might be messy to  
implement, though; it would require parsing (albeit fairly simple  
parsing).

>> WRT Proxy-Authorization: Authorization is allowed to be  
>> overwritten, so it seems reasonable to allow Proxy-Auth too  
>> (although the use case would indeed be pretty esoteric; I suppose  
>> someone doing something inside the firewall might want to do  
>> something here...)
>
> I don't think you can ever safely assume what proxy is being used,  
> so it seems like it would never be right to use this. Keep in mind  
> that the proxy settings can generally be changed by the user at any  
> time, even while a script is running.

Good point. I'm inclined to agree.

> What about Via?

Via is used for debugging, it doesn't have any assigned behaviours.  
Worst case, somebody can insert a false via at the front of the queue.

>>> Your list also includes Accept-Charset, I think that one could  
>>> reasonably either be forbidden or allowed.
>>
>> Does DOMString expose the character encoding? I thought it was  
>> just a character abstraction based on Unicode (again, I'm not a  
>> DOM expert, much less an i18n one...)
>
> I think the reason to possibly allow it is that it could be useful  
> in some cases. And some implementations could have extensions that  
> offer direct access to the response body as an octet stream. In  
> such implementations it wouldn't necessarily result in content that  
> couldn't be handled.

If there's a possibility that someone wants to access the raw bytes  
of a textual type (which is what Accept-Charset implies), sure. I  
just can't think of any situation where that would be useful...


--
Mark Nottingham
mnot@yahoo-inc.com

Received on Wednesday, 3 May 2006 19:21:54 UTC