- From: Adam Barth <ietf@adambarth.com>
- Date: Mon, 1 Nov 2010 19:56:15 -0700
- To: httpbis <ietf-http-wg@w3.org>
On Mon, Nov 1, 2010 at 5:43 PM, Mark Nottingham <mnot@mnot.net> wrote: >> => a header field value with multiple instances of the same parameter >> SHOULD be treated as invalid. >> >> Similarly, this requirement probably should read "user agents SHOULD >> treat a header field value with multiple instances of the same >> paramater as invalid." Furthermore, the document should define what >> treating a header field value as invalid means. Presumably the author >> intends that user agents ought to ignore such header field values. >> I'm skeptical that is the optimum behavior for user agents. I would >> have expected user agents to either use the first or the last instance >> of each paramater. > > Ticket: > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/259 > > Note that it may be resolved by indicating that 'treat as invalid' is specific to the application at hand. As such, I'd like initial discussion of this in the WG to focus on: > a) use cases: how different implementations / applications may want to have different notions of 'invalid' (or not), and The browser use case proceeds from the following premises. 1) Many servers send invalid messages to user agents. 2) Many existing user agents have some behavior for these invalid messages. 3) If a new user agent wishes to compete in the market, that user agent needs to handle the invalid messages in the same way as the existing user agents. Use case: Users benefit when there is competition among browser vendors. Without specifying how to handle invalid messages, new user agents need to reverse engineer the behavior of existing user agents, making it more difficult to compete in the marketplace. > b) security: what the security impact of having different notions of 'invalid' here may be, and > c) interoperability: likewise, the interop impact. The largest interoperability problems here are the different user agents handle invalid messages differently. For example, today, it's unpredictable how user agents will interpret a filename parameter with a % character. That part of the protocol is less useful to servers because the results are not predictable. Adam
Received on Tuesday, 2 November 2010 02:57:21 UTC