- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Thu, 14 Jun 2012 09:04:23 +0000 (UTC)
- To: ietf-http-wg@w3.org
Mark Nottingham <mnot@...> writes: > On 14/06/2012, at 9:23 AM, Amos Jeffries wrote: > > Would these types of differentiation between reasons for rejection be a good case for Warning: codes on a > 403 response? > > > > ie > > Warning: ... Legal Restriction > > Warning: ... Local administrative policy > > Warning: ... Authentication failed too many times. Your account is now closed > > ... > > > > The body of 403 can as easily contain the legal disclaimer text as any other 4xx code. > > So, again -- what's the use case for a machine consuming these? I haven't seen one yet, unless I've missed something. 1. the block cause must be reflected in headers to be available in (legal or debugging) logs. With today's spaghetti web sites that shard their content over multiple servers and delegate more and more bits to nebulous cloud platforms with fuzzy limits having to read all the html pages exchanged to debug a block is increasingly un-practical 2. the block cause must be reflected in headers so all the web clients that use http as transport via some other middleware can be notified of the block cause (ie the not-html-capable http middleware needs something it can easily parse and pass up the stack so the web client presentation layer gets a chance to do something with it and inform the user) 3. the info must absolutely be relayed to the human user so he gets a chance to do something about it. 4. The info must be complete enough the human user can act on it. Going to the hotel lobby to buy some more creds is not the same thing as being invited to the local police station to explain oneself 5. There must be a way to inform the user ways to lift the block when the possibility exists instead of having him hang in the dark (hotel payment gateway 'credit-exhausted pay-here-to-continue', corporate authentication portal 'are-you-an-employee fill-in-your-corp-login-there', 'content-was-blocked-because-we-believe-it-is-objectionnable, here-is-the-html-form-to-contest-the-evaluation-if-you-believe-it-is-wrong', etc, etc) None of those work of you rely on an html soup error page that may or may not be parsed by the web client, or that you let the web client ignore at will even when it is capable of parsing (current browsers refuse to display such pages when a block occurs over https) -- Nicolas Mailhot
Received on Thursday, 14 June 2012 09:05:05 UTC