- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Wed, 13 Jun 2012 09:44:38 +0000 (UTC)
- To: ietf-http-wg@w3.org
Willy Tarreau <w <at> 1wt.eu> writes: > I don't completely agree here : for me, 5xx means that the error is not > the client's fault and that it might randomly work if the client tries > again, which is why network errors fall into this category, as opposed > to the 4xx error by the user/user agent as you explained (and which I > agree with). I'd say there is not a sliver of technical difference between the blocking done by an hotel wifi portal, by a school gateway on lab internet accesses, by a home proxy on pornography accesses by children gadgets, by a corporate proxy on facebook accesses, by a conference gateway for visitors, by an isp or country filtering infra on stuff the country decided is not legitimate (and in all those cases the equipments used are pretty much the same and marketed by the same companies). At every point the web client requested a web resource and it was denied by some intermediary for violating the terms of use. What varies is only the ultimate human justification behind the blocking (financial, organisational, legal…): what the terms of use are based on, how to get the level of access to bypass it (I'm pretty sure that even in politically-challenged countries spooks get to see what is blocked), etc But this justification is not something software should act on, it's something for humans to act on (and I'm not saying I agree with all the possible kinds of blocking, just that technically they are all the same). It is completely wrong to try to enshrine political assessments in technical protocols, the protocols must provide the technical means to communicate there is some form of blocking, where the (human) justification can be found (law/terms of uses), and where the user can provide credentials to lift the blocking in the case it has this possibility (prove he paid the bill in case of hotel accesses, prove he is staff for school labs/conferences, prove he is marketing for facebook access in the Enterprise, that he is of legal age to see nudity etc) So the semantics should be the same as error 511 and I'd go as far as to say error 511 should be generalised to handle those cases. What error 511 is missing is: 1. a clear definition of 'terms of use' (what humans needs to read to understand why access is blocked) and 'authentication means' (where the user or software can provide credentials to get elevated access). This is especially important in russian doll scenarii where the blocking can occur at different levels and the different levels are not the same at all for users (a conference in a repressive country for example: blocking can occur at the conference gateway level, at the isp used by the conference, or at the national firewall level) 2. how this information is conveyed to users (a free-form html page does not work for dumb clients or fat clients that use an http library such as curl). 'terms of use' and 'authentication means' location need to be specified in http headers so the http library can pass it up the stack and the developer can choose to display it (or not) in a browser window, an app popup or whatever he deems appropriate 3. guidance to web client implementers on the security precautions to apply when conveying this info to the user, and how to convey it even when the blocking occurs mid-browsing in an https session And it is not helping the user to refuse to acknowledge reality and hide this information (when it is available). If the user does not even know it is blocked and why he can not act at all (politically or otherwise) Regards -- Nicolas Mailhot
Received on Wednesday, 13 June 2012 09:46:51 UTC