Re: [#95] Multiple Content-Lengths

On Sep 20, 2010, at 3:35 PM, Roy T. Fielding wrote:

> On Sep 20, 2010, at 1:06 AM, Anne van Kesteren wrote:
> 
>> On Mon, 20 Sep 2010 07:57:56 +0200, Mark Nottingham <mnot@mnot.net> wrote:
>>> Two replied that they have concerns about displaying errors to end users. If they come on-list and discuss their concerns, we can discuss this more.
>> 
>> I was one of those if I remember correctly. End users just do not understand such error messages. And since they cannot do anything with them either showing error messages to end users will just make them confused, which gives them a bad product experience. It is exactly the same problem with asking users if they are okay with doing the request using the method CHICKEN to this other location. They'll just go "WTF" hit "OK" and hope it works, which is not that great really. Or worse, terminate the browser and start over.
> 
> Please, let's focus on what is actually written for the spec and
> not on vague generalities of what an error message might be.
> The spec draft 11 says
> 
>      If this is a
>      response message received by a user-agent, the message-body
>      length is determined by reading the connection until it is
>      closed; an error SHOULD be indicated to the user.
> 
> It does not say that an error is displayed in a dialog box that
> the user must click OK upon.  It does not describe a user interface
> requirement in any way, shape, or form.  How a user agent indicates
> anything to a user is dependent on the type and style of the UA.
> For example, the tiny little conformance violation icon in the
> corner of Firefox's window is sufficient to indicate an error.
> So is an error log.
> 
> The reason to indicate the error is because the user agent has
> no way to know whether it is actually rendering the message as
> desired by the server or possibly several responses or possibly
> a corrupted or truncated response.  Failure to note such things
> as errors can result in very unsafe results for some applications
> of the Web, such as medical information systems.

If the situation is so dangerous, then the UA should not present the response at all and instead should fail with a hard error. Presenting the response and then also showing an error message sends confusing mixed signals to the user. It does not provide an effective defense against security violations. A hidden error message (e.g. in the error log) will also not protect the user in the case of either a security attack or a garbled message - how would they know to look? Users don't check the error log periodically to see if they have been hacked. Furthermore, the damage may have already been done if the response is presented at all, and users will not be helped by being told about it after the fact.

Therefore, processing the response and also signaling an error is my least preferred option. Either processing the response is dangerous, in which case it should be completely rejected, or it is not all that dangerous, in which case there should be no mandated warning or error. UAs may wish to signal the problem in developer tools for debugging purposes, but that is a quality-of-implementation issue, and should be up to the judgment of the tool developers.

Regards,
Maciej

Received on Friday, 8 October 2010 18:12:24 UTC