W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

TICKET 259: 'treat as invalid' not defined

From: Adam Barth <ietf@adambarth.com>
Date: Mon, 1 Nov 2010 19:56:15 -0700
Message-ID: <AANLkTikXX0gZqT8Eo+FZ3=JE-5LzYP1GYLoC8uw94cTV@mail.gmail.com>
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.

Received on Tuesday, 2 November 2010 02:57:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC