Re: Headers / caches proposal (revised)

On May 2, 2006, at 6:11 PM, Mark Nottingham wrote:

>
> On 2006/05/02, at 1:33 AM, Maciej Stachowiak wrote:
>
>> Combining these lists, your list does not include Connection,  
>> Upgrade, Expect, Via, From, Max-Forwards or Proxy-Authorization.  
>> Are you convinced all those are safe? Do you think my specific  
>> justifications for Connection, Upgrade and Expect were wrong?
>
> 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).
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.


> WRT Upgrade: I think you're right.
>
> WRT Expect: I think you're right, but there should also be a  
> section about E/C handling in send().
>
> WRT From: I don't think any software actually uses this to inform  
> behaviour; it's just a way to give a more persistent address for  
> the user.

Well, I just thought it seemed suspicious. I'm not sure it is  
actively bad.

>
> WRT Max-Forwards: I'm ambivalent about this one. It could be useful  
> in debugging proxies, etc. and it has pretty well-defined behaviour...

Ditto.

> 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.

What about Via?

>> 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.

>
>> I also think the spec should justify why headers are disallowed  
>> rather than just stating it, it seems oddly out of context to just  
>> give an arbitrary list.
>
> It was discussed at the F2F yesterday; that might be contributing  
> to that oddness. I agree there should be justification, but I don't  
> know that the spec text needs to show the math, so to speak.

The reason I think this should be in the spec is so that future  
generations reading the spec will get the reasoning when discussing  
these issues. I am not sure having the justifications in the w3c  
archives is enough. It will increase the odds of implementors  
actually paying attention to the spec, and future generations  
applying correct reasoning when revising the spec. But I don't think  
this is essential, since the justifications would not be normative.

Regards,
Maciej