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

On 14/06/2012, at 7:04 PM, Nicolas Mailhot wrote:

> Mark Nottingham <mnot@...> writes:
>> 
>> 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

The device doing the blocking can log its own actions without making it machine-readable on the wire. 


> 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)

Yes; this is the most compelling case I can see for a separate status code, similar to the one we had for 511. However, I don't yet see where the client will actually *do* something with the response that might require making this distinction. It was necessary in 511 because sites were interpreting the redirect as coming from the origin server, which has all sorts of nasty side effects for non-browser agents; what are the corresponding side effects here?


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

That really sounds like HTML; most browsers don't expose the raw status code.


> 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

Same as #3.


> 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',
> 'content-was-blocked-because-we-believe-it-is-objectionnable,
> here-is-the-html-form-to-contest-the-evaluation-if-you-believe-it-is-wrong',
> etc, etc)

How is that accomplished by a status code, and NOT by HTML?


> 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)


None of these? Really?

Understand -- I'm not against minting a status code here per se, but if we do it, I want it to be for technically valid reasons, not just to scratch an itch to make developers feel more politically active, with no real-world deployment.

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 14 June 2012 10:14:56 UTC