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

Le Jeu 14 juin 2012 15:02, Julian Reschke a écrit :

> This really, really smells like over-engineering to me. Also, HTTP
> header fields are a very bad solution to transporting human-readable
> text; that's what we have markup languages for.
>
> It probably would be useful if you could walk us through a concrete use
> case where a status code + response body is not sufficient. (And if you
> did before, sorry, then please provide a pointer).

Some use cases and problems (not exhaustive):

A. employee is visiting a foreign location. For safety reasons his laptop is
configured to only access the internet through corporate proxies that will
perform a set of anti-malware checks. To reach those proxies he needs to
launch a vpn on log in. The hotel has a captive portal.

Any web access will only succeed if:
1. the captive portal lets it pass
2. the vpn is set up
3. the corporate proxy okays it

So in this very simple case you have three levels of gateways to pass, one web
client (the vpn client) that is unable to process any complex html code, and a
non-technical user very far from any help.

For this setup to work the hotel captive portal needs to send the vpn client
something simple enough the vpn client recognizes it's a gateway portal
request, and lets the browser connect to it directly instead of passing
through the (not yet available) proxy

The vpn client can not read html.

If browsing is blocked at any point later the user needs to know if it's
because he needs to pay more at the hotel or because his access is blocked by
corporate policy. Hopefully in a non-spoofable way (so need to point to an
auth/explanation location secured by its own known certificate, not a naked
415 page)

B. A company has redundant filtering internet gateways. They do not share
authentication realms (because that is hard to do without making the gateways
dependant on one another). Web clients know both gateways through a .pac file
and decide to switch from one to another for their own reasons (typically,
"web site is slow to answer, let's try the other gateway in case it works
better"). When user auth expires the user need to be notified by the browser
even if he's mid https session, the notification must point to the correct
auth portal (the user has no idea which gateway his browser decided to try at
this moment, and besides its all technical mumbo-jumbo for him), and it must
be explicit enough one can hope to plug a password/certificate manager over it
someday

C. A company authorises direct access to an internal web app by another
company. If blocking occurs at any point the users of this other company must
be informed if the blocking is done by first company network, second company
network or if the app itself has a bug (that needs to be reported to its
application maintenance team)

D. Any time blocking occurs when a user POSTs some data, if the browser is not
aware that the user or some password manager resolved the blockage by
successfully supplying credentials to the location specified in the blocking
error, and if the browser does not then auto-retry the access that failed
before, the post content will be lost (because teaching non-technical users to
refresh the correct page at the correct time manually is a lost cause)

Browser can not know a specific location unlocks the gateway if it is not
specified at the http level and if there is no standard code that conveys
successful unlocking

(you could hide this complexity via various URL redirect tricks, but browsers
block them on https for security reasons nowadays so now the browser itself
must initiate the reloading of the blocked post when it is possible to do so
again)

E. Access is blocked. Users do not understand simple explanations and need
lots of pictures and text. Those explanations are provided in the error page
itself instead of a separate location. Frustrated users do not read the
explanations and just retry in a loop. Gateway melts under the load. No access
is possible for anyone anymore (even accesses for users that were not blocked
previously)

D. Same scenario but this time the network equipment can only provide a single
page with no external dependencies at all. Loads of not-fun with embedded
data: references to try to push the info anyway

E. Any fat client situation (eclipse, git, wget scripts, various rcp or dotnet
clients developed using traditional client/server mindset and that use http
transport because of-the-shelf libraries are available and this way they don't
have to ask to open new ports on the corporate firewalls). None of those will
be able to render a complex html page. All of those can easily be upgraded to
display a short error text on a specific error code and an url the user can
then launch in his browser

D. Any loging/debuging scenario where web pages bodies will be typically
ignored (to limit logging cost) but http envelope won't

E. Any scenario where you're worried about spoofing and would like your users
to check the reason given in the short error before opening a complete
(possiby hostile) site (just like you'd want them to check mail titles before
acting on their content)

F. If you don't add some free-form text to the error code you'll have to
invent new error codes for each blocking situation instead of having a single
one everyone can implement support for

You could perhaps get by with only the two location headers (one for the fine
manual no one will read but everyone will complain at if it's missing, the
other for the un-block location that will be heavily used) but it's a lot
easier to have a short text that says 'blocked due to rule 22' or 'blocked due
to rule 5' and in both cases point to the same terms of use web page/pdf, than
to try to have separate stable entry points for all the possible block reasons
as soon as you have non-trivial terms of use.

And fat client presentation layer will really want to have some short text to
print before naked urls. If you don't give it to them they'll invent something
(that will likely not represent accurately all blocking scenarii)

-- 
Nicolas Mailhot

Received on Thursday, 14 June 2012 15:25:29 UTC