- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Mon, 11 Jun 2012 10:19:48 +0000 (UTC)
- To: ietf-http-wg@w3.org
Yoav Nir <ynir@...> writes: > Thinking it over, the message is supposed to be sent to humans, not machines. So the correct thing would be to redirect to a service-provider hosted page, that says what was blocked and why. 1. browsers will silently block the redirect if the original request was for an https URL, so that does not work 2. some dumb clients will loop over redirects they don't understand 3. dumb web clients can not parse a complex html page and need the response in a header or something simple they can grab and relay elsewhere (for example a fat client that uses curl or some other http lib: curl needs to grab the message so the fat client can display it in a popup) 4. the message is not always a simple no (at a conference/school guests will have limited accesses but staff no so the message could be 'go authentify yourself there to prove you're staff before I let you access what you requested') 5. the 'authentify there' can vary depending on what you're trying to access (not all network traffic will be routed through the same gateways) 6. ideally the message needs to be signed by the requesting authority so it can not be spoofed by truants
Received on Monday, 11 June 2012 10:20:26 UTC