Re: Headers / caches proposal (revised)

[Maciej Stachowiak]

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