Re: Reviving discussion on error code 451

On Thu, Dec 18, 2014 at 10:34:16AM +0100, Stefan Eissing wrote:
> 
> > Am 18.12.2014 um 10:12 schrieb Eliot Lear <lear@cisco.com>:
> > [...] I did, however, ask questions in order to understand what
> > programmatic behavior you expect in reaction to this response code that
> > would differ from at least one existing response code.  To me at least,
> > that's what these low level HTTP response codes are for, and I probed
> > whether the code could be generalized. [...]
> 
> Can you give examples in the description of existing codes like 402, 403,
> 404, 405, 406, 408, 409, 413, 414 about what you expect this draft to do for
> 451 beyond what is there? I regard the 451 documentation to be in the spirit
> of the other HTTP status code documentations, so I do not see your problem.

OK that's getting annoying now. Here's how a status code is generally
documented :

===========
  6.5.3. 403 Forbidden

   The 403 (Forbidden) status code indicates that the server understood
   the request but refuses to authorize it.  A server that wishes to
   make public why the request has been forbidden can describe that
   reason in the response payload (if any).

   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.  The client
   SHOULD NOT automatically repeat the request with the same
   credentials.  The client MAY repeat the request with new or different
   credentials.  However, a request might be forbidden for reasons
   unrelated to the credentials.

   An origin server that wishes to "hide" the current existence of a
   forbidden target resource MAY instead respond with a status code of
   404 (Not Found).
===========

It indicates in what situation the code ought to be emitted, in what
situation it is not appropriate, and how the client has to deal with
it. There is no such thing in the aforementionned draft which basically
says "if you want to indicate legal reason, use 451".

What needs to be specified at least :
  - when to emit that code
  - when not to emit it and what to do instead
  - how does the client react, may it retry or not
  - how does the client know when/why these contents were marked illegal,
    and how long may it cache that information if appropriate
  - how does the client know that the legal issue is for the server or
    the client (which will tell it whether it may retry somewhere else
    or not).
  - how does the client know whether it is the body it's being uploaded
    or the what it tries to retrieve which is tagged illegal.

I'm seeing at least 3 situations which deserve emitting a code, possibly
different :
  - client tries to fetch data that a server is not allowed to deliver
    because that content was tagged illegal after the URL was published,
    and the server wants to stipulate that (eg: stolen documents). The
    client knows that maybe that content is illegal only where the server
    resides and the same content might legally be fetched somewhere else.
    This can be true for crypto code or books for example.

  - client tries to fetch data that is not legal to have in the country
    where he resides. Typically adult contents when the age of the human
    in front of the computer is known. Not all countries have the same
    rules about this, and servers might refuse to deliver certain contents
    to certain people. The client then knows it's inappropriate to look
    for the same contents somewhere else.

  - client tries to upload some illegal contents to a file sharing site,
    for example a document, a movie or whatever that is not permitted by
    law where the server resides. It should be clearly mentionned as well.

All these 3 cases are very different and all fall under the same vague
terms of the current draft. These need to be clarified.

For now the draft only looks like the work of someone wanting to have fun,
and not anything with any technical merit at all. And I already got that
feeling back then in 2012 when the discussions started.

Regards,
Willy

Received on Thursday, 18 December 2014 10:20:44 UTC