- From: John Sullivan <jsullivan@velocix.com>
- Date: Fri, 15 Jun 2012 15:11:09 +0100
- To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- CC: <ietf-http-wg@w3.org>, Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, <tbray@textuality.com>, <w@1wt.eu>
Nicolas Mailhot wrote: > 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. No, the expectation is that the block is permanent, the entity implementing the block *wants* to (semi)permanently pollute that URL, retries are unlikely to be useful. The user *might* be able to get the block lifted by complaining to the right place, but that's a longer process. In some cases the local sysadmin might agree a particular URL is blocked in error with an email round-trip, in some cases it might take societal upheaval to get the blocking policy changed. > 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 For 511/captive portal the situation is that the user probably can rapidly resolve the block themselves, either by completing the attached form, or by phoning/walking to reception etc, and then trying again. The blocker doesn't want to break that access permanently, they just want to get paid for it first, but I don't see how except in vanishingly rare cases there could be fully automatic recovery, it's going to require some form of user action. John --
Received on Friday, 15 June 2012 14:11:42 UTC