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

On 2012-06-15 09:33, Nicolas Mailhot wrote:
> (Apologies for replying to myself)
>
> To put the point shorter, I think the core problem with "assign a generic
> code, put human explanations in html or xml body" is that's a layering
> violation for all applications that use http as transport.
>
> Those applications (reasonably) expect being able to set up the transport at
> the http level without ever having to parse metalanguage bodies. When you put
> relevant transport information in metalanguage bodies, you break this
> expectation.
>
> And in case of blocking or censorship, transport set up does not stop at
> punting a metalanguage error to the human. In all but the most extreme cases
> it is possible to lift all or part of the blocking by providing some
> credentials or tokens somewhere, and to avoid breaking web apps that were
> mid-transaction when the block occurred, the web client must then retry the
> access that was blocked.
>
> There are several possible designs. The full one in proposed yesterday. The
> others are (if I've followed the discussion correctly) :
>
> A.
>
> 1. Generic 'blocked by intermediary' code
> 2. All other information somewhere in a metalanguage body
>
> That's error 511 design. The cons are that it is useless for dumb clients,
> there is no clear way to unlock except by parsing not-standardised
> metalanguage soup, the blocking cause is not explicit at the http level in
> logs (you need to infer it from what emitted this error), it's a transport

That's not helpful. I hate tag soup as much as you, but in the end it's 
simply HTML, *is* standardized, and has tons of implementations.

> layering violation, and in cases when your network equipment can not host a
> full web site you have to stuff all the rationale in the error body, even if
> most users don't need to read it twice, and it needlessly overloads the wire.
> ...

For 511, the reason for the scope of the spec is that for the case it 
covers, there is no protocol around that can be used. The network 
authentication dialogue *is* HTML, and those who design and deploy these 
devices see no need to make it more complicated. After all, it "works" 
(mostly).

The spec for 511 just addresses one specific problem (this content being 
sent with a success status), nothing more. The scope is *intentionally* 
constrained. That's not an error.

Best regards, Julian

Received on Friday, 15 June 2012 07:43:27 UTC