Re: Reviving discussion on error code 451

On Thu, Dec 18, 2014 at 01:28:20PM +0100, Stefan Eissing wrote:
> > Am 18.12.2014 um 12:33 schrieb Willy Tarreau <w@1wt.eu>:
> > 
> > On Thu, Dec 18, 2014 at 12:09:25PM +0100, Stefan Eissing wrote:
> >> Proposal:
> >> -------------------------------------------------------------------
> >> 451 Unavailable For Legal Reasons
> >> 
> >>  The 451 (Unavailable For Legal Reasons) status code indicates that
> >>  the server understood the request but is unable to fulfill it due
> >>  to legal reasons. Responses using this status code SHOULD include 
> >>  an explanation, in the response body, of the details of the legal 
> >>  restriction; which legal authority is imposing it, and what class 
> >>  of resources it applies to. For example:
> > 
> > (...)
> >> I hope the description above makes it more clear that 451 would apply to
> >> retrievals. E.g. the first 2 of the 3 situations you describe. As with 403, I
> >> see no need to have differentiate situations 1+2.
> > 
> > No. "unable to fulfull the request" does not imply retrieval, I'm sorry.
> No need to feel sorry for this. I think the status code is about retrieval
> and the draft should define that. If that is not clear, wording should be
> made clear. Feel free to contribute.

That's what I'm doing by explaining my view that this should be split in
at least 3 distinct responses, possibly codes and providing examples.

> > Also, I see a big difference between the two cases (server-side legal issues
> > or client-side legal issues), it's for caches. A cache should possibly cache
> > a server-side legal blocking while it must not cache the client-side one,
> > unless it's installed on the client-side and is concerned by the same
> > legal issue.
> 
> Cacheablility of responses is defined in rfc7234 ch. 3 quite well. What do
> you think needs additionally be said? What mechanisms need to be added
> for this status code that are not already available?

It's different here because the rule can vary according to where the cache
is located. If you have two distinct codes, you can allow a client-side
cache to cache certain responses and a server-side one to cache other
responses. I don't see how you can currently use something like
"vary: client-ip" to indicate that he response varies depending on the
client's address.

> I think the 30x "mess" resulted mainly from the evolution of the use cases
> and the experiences gathered over the years.

Not exactly, POST already existed, it's just that combinations of cases
were not imagined back then. Here some combinations are already identified
and only summarized together under the same code. That's for sure seeking
for later problems.

Willy

Received on Thursday, 18 December 2014 12:42:17 UTC