W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: New Version Notification for draft-tbray-http-legally-restricted-status-00.txt

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Thu, 14 Jun 2012 09:04:23 +0000 (UTC)
To: ietf-http-wg@w3.org
Message-ID: <loom.20120614T104702-439@post.gmane.org>
Mark Nottingham <mnot@...> writes:

> On 14/06/2012, at 9:23 AM, Amos Jeffries wrote:

> > Would these types of differentiation between reasons for rejection be a good
case for Warning: codes on a
> 403 response?
> > 
> > ie
> > Warning: ... Legal Restriction
> > Warning: ... Local administrative policy
> > Warning: ... Authentication failed too many times. Your account is now closed
> > ...
> > 
> > The body of 403 can as easily contain the legal disclaimer text as any other
4xx code.
> So, again -- what's the use case for a machine consuming these? I haven't seen
one yet, unless I've missed something.

1. the block cause must be reflected in headers to be available in (legal or
debugging) logs. With today's spaghetti web sites that shard their content over
multiple servers and delegate more and more bits to nebulous cloud platforms
with fuzzy limits having to read all the html pages exchanged to debug a block
is increasingly un-practical

2. the block cause must be reflected in headers so all the web clients that use
http as transport via some other middleware can be notified of the block cause
(ie the not-html-capable http middleware needs something it can easily parse and
pass up the stack so the web client presentation layer gets a chance to do
something with it and inform the user)

3. the info must absolutely be relayed to the human user so he gets a chance to
do something about it.

4. The info must be complete enough the human user can act on it. Going to the
hotel lobby to buy some more creds is not the same thing as being invited to the
local police station to explain oneself

5. There must be a way to inform the user ways to lift the block when the
possibility exists instead of having him hang in the dark (hotel payment gateway
'credit-exhausted pay-here-to-continue', corporate authentication portal
'are-you-an-employee fill-in-your-corp-login-there',
etc, etc)

None of those work of you rely on an html soup error page that may or may not be
parsed by the web client, or that you let the web client ignore at will even
when it is capable of parsing (current browsers refuse to display such pages
when a block occurs over https)

Nicolas Mailhot
Received on Thursday, 14 June 2012 09:05:05 UTC

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