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
[EMAIL PROTECTED]
