Subject: DELETE and 410 Gone

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 08:25:44 -0400

in DELETE section [1], it might be worth to add a paragraph.

    Once the server has successfully completed
    the DELETE, a server response on any 
    subsequent requests on the same URI SHOULD be 
    410 (Gone) (See section 8.4.11 of [Part2]).

Rationale: people hesitate on what they can do once the DELETE has been accomplished.

[1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.7

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 25 Aug 2011 13:33:42 +0100

Karl,

That makes a lot of sense. Is it worth mentioning that obviously the 410
state only counts unless the content is replaced later, or is that
sufficiently implied?

Ross

On 25/08/2011 13:25, "Karl Dubost" <[email-masked]> wrote:

>[1]: 
>http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.7
>
>--

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Aug 2011 14:48:59 +0200

>      410 (Gone) (See section 8.4.11 of [Part2]).

Why?

Why not 404?

And 200 is possible once the URI gets mapped again...

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 25 Aug 2011 13:54:05 +0100

404 implies that the address was never valid, whereas 410 indicates that
it was previously valid, but is no longer. This is useful, for example, to
make it clear that the address was not mis-entered, but that it's
deliberately been removed.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Aug 2011 14:56:27 +0200

> deliberately been removed.

Can you back those claims with citations from the spec?

Best regards, Julian

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 25 Aug 2011 14:07:57 +0100

Apologies, slight correction, 404 doesn't specifically imply anything,
however I think the point that 410 is useful to indicate a resource
previously existed:

"The 410 (Gone) status code SHOULD be used if the server knows, through
some internally configurable mechanism, that an old resource is
permanently unavailable and has no forwarding address."

- 10.4.5 in RFC 2616 (
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html )

"The requested resource is no longer available at the server and no
forwarding address is known."

- 104.11 in RFC 2616 (
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html )

So, it's not explicitly stated that a resource MUST have previously
existed for a 410 status to be returned, but I think reasonably implied.

---

From: Alexandre Morgaut <[email-masked]>
Date: Thu, 25 Aug 2011 15:10:15 +0200

> deliberately been removed.

This difference is an interesting piece of information to give to the user but for some privacy policy it might also be a lack of security. I have myself already used the 410 status code in this case but I wouldn't do it every-time for any kind of resource.

I think it is interesting to promote this status code after a DELETE, but not with a SHOULD. Even more, I would explain the impact of such a use.

>> And 200 is possible once the URI gets mapped again...

Alexandre Morgaut
Product Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    [email-masked]
Web :      www.4D.com

---

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 10:35:14 -0400

Alexandre, Julian,

Le 25 août 2011 à 09:10, Alexandre Morgaut a écrit :
> This difference is an interesting piece of information to give to the user but for some privacy policy it might also be a lack of security.

Ah! interesting. Tell us more. 

> And 200 is possible once the URI gets mapped again...

Why 410 Gone? 
because I had the feeling it was a good practice aka for intermediaries and search engines to say forget about this URI. There was something here indeed it is not a mistake but it is just gone for good. 

Why not 404?
in 404 section
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-8.4.5

   "The 410 (Gone) status code SHOULD be used if the server
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address."

Typically this is the case after a DELETE where the server is informed to remove access to the resource. 

Yup 200 is possible if you map it again. No issue with that. There is a question of right balance. If you know that it is a temporary condition, you might design your server with a 404 response, but if you are sure that you have remove access to this resource for a long period of time (subjective but like everything in HTTP), 410 Gone is a good fit. 

I can modify the proposed text (modulo privacy/security issues to come)

   Once the server has successfully completed
   the DELETE, and the intent of this DELETE is 
   permanent, a server response on any subsequent 
   requests on the same URI SHOULD be 410 (Gone) 
   (See section 8.4.11 of [Part2]).

privacy, security, I want to hear more about it. :)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Aug 2011 16:44:55 +0200

On 2011-08-25 16:35, Karl Dubost wrote:
> ...

How would the server know that the DELETE wasn't a "mistake"? I don't 
believe it can know that.

Best regards, Julian

---

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 11:38:27 -0400

Le 25 août 2011 à 10:44, Julian Reschke a écrit :
> How would the server know that the DELETE wasn't a "mistake"? I don't believe it can know that.

indeed but this is true for everything, and every code. :)
There are intents behind each actions of the protocols, which define human interactions in a communication space.

---

From: Alexandre Morgaut <[email-masked]>
Date: Thu, 25 Aug 2011 18:08:07 +0200

> Ah! interesting. Tell us more.

In Europe there is a very important topic called in French "droit a l'oubli numérique"
A bit hard to translate... It means, if you have, or other have, put some of your private data on the Web, but later, you want/need this data to be removed, you should be able to do it. There is Lawers working hard on that. This requirement may aslo occur on public data.

Use cases:
 - change of identity of somebody, maybe a whole family for their security
 - someone is tagged by a third party on a picture and want this tag to be removed (the picture may be completly unrelated to the person like a porn or a racist picture just to give him a bad reputation)

The fact is that with some very google friendly URL anyone could try some manually constructed URL to know if something has be related to another

ex:
Someone told me this guy was member of this organization
I check

-> GET http://thisorganiztion.org/members/john-doe
<- 410 Gone HTTP1/1

If this wanted all his informations being removed from this organization website (he may not agree any more with its actions), here there is a problem...

Regards,

Alexandre Morgaut
Product Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 25 Aug 2011 18:00:24 +0100

> If this wanted all his informations being removed from this organization website (he may not agree any more with its actions), here there is a problem...

I think what you've argued here is more that the entire 410 status code 
needs to be deprecated or have significant notes about privacy added, 
than the specific case of what happens after a DELETE operation. Which 
is fair, but I think an important distinction.

Assuming the 410 status code isn't going anywhere, I think "response on 
any subsequent requests on the same URI SHOULD be 410 (Gone)" is fine, 
as there's a SHOULD (appropriate to most cases) but if a server admin 
feels a need to return 404 instead they have that option.

Ross

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 25 Aug 2011 13:18:11 -0700

> [1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.7

That would be false.

410 is a deliberate decision by the resource owner that says the
resource is gone -- not to be found here again, ever.  They have
to configure it explicitly.

404 is a statement that no representation for the resource has
been found at the time of the request.  Mappings are discontinuous.
It is the natural state after a DELETE, but certainly isn't required.

Either one could be appropriate following a DELETE.  For that matter,
so could 403, 401, etc.

Tools that perform a DELETE should be encouraged to provide options
for the user to do something else with that resource after the DELETE,
but I have no idea how that would appear in prose in a manner that is
compatible with all the various usages of HTTP.

....Roy

---

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 16:44:03 -0400

> to configure it explicitly.

I understand this. :) And the rationales which have been given. 

> It is the natural state after a DELETE, but certainly isn't required.

Note that I didn't make it required either. 

Let's go back to something more practical in which concrete cases right now the DELETE is used on the Web. I had the impression that if someone was sending a DELETE, it meant "resource owner that says the resource is gone".

Any other use cases?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 25 Aug 2011 13:56:11 -0700

> Let's go back to something more practical in which concrete cases right now the DELETE is used on the Web. I had the impression that if someone was sending a DELETE, it meant "resource owner that s…

It actually means remove the current representation.
The resource is the mapping over time, and hence can't
be deleted.

....Roy

---

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 17:09:49 -0400

> The resource is the mapping over time, and hence can't

Do you mean for example a practical case of a resource with multiple representations? 

http://example.com/foo

with two representations
image/png
image/jpeg

And use DELETE to remove one of them?

---

From: Alexandre Morgaut <[email-masked]>
Date: Thu, 25 Aug 2011 23:13:14 +0200

On 25 août 2011, at 22:56, Roy T. Fielding wrote:

it can't be deleted but it's up to the server to return a 404 (Not Found) or 410 (Gone) status information to preserve privacy, or on other side provide more informations ;-)

Alexandre Morgaut
Product Manager
Email : [email-masked]<mailto:[email-masked]>
Web :   www.4D.com<http://www.4D.com>

4D SAS
60, rue d'Alsace
92110 Clichy - France

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 25 Aug 2011 14:22:19 -0700

> And use DELETE to remove one of them?

No, it removes all current representations.  It is the equivalent
of rm in the Unix filesystem -- it removes the current association
between the name and whatever that name formerly mapped to.
In essence, it deletes the name from the directory record and
may (or may not) have some impact on the storage system as a
result.  It does not prevent the next request from recreating the
same name via PUT, and hence does not delete the resource because
the identifier is still valid.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 25 Aug 2011 14:24:22 -0700

> it can't be deleted but it's up to the server to return a 404 (Not Found) or 410 (Gone) status information to preserve privacy, or on other side provide more informations ;-)

The server can do whatever it wants to do, including telling the
client okay to the DELETE and then creating a new representation for
that resource a minute later.  Whether or not that makes sense
depends entirely on the meaning of that resource -- not HTTP.

....Roy

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 26 Aug 2011 07:49:05 +0800

On 2011-08-26 at 07:24:22, Roy T. Fielding wrote:
> that resource a minute later.  Whether or not that makes sense depends 
> entirely on the meaning of that resource -- not HTTP.

I've always found 410 to be a bit weird.  The idea that *any* information about a particular resource can be considered permanent is antithetical to my understanding of the way the system works.

--Martin

---

From: Karl Dubost <[email-masked]>
Date: Thu, 25 Aug 2011 21:44:01 -0400

> I've always found 410 to be a bit weird.  The idea that *any* information about a particular resource can be considered permanent is antithetical to my understanding of the way the system works.

Nathan has asked a few questions about it.

    2: Can/could 410 Gone response include 
       a Last-Modified header?
    — [1] Resource states (initial and final)

and an indirect question about can a server tell a resource is non existant. [2], which mentioned a few times 410. 

But what is interesting (to me) is that 410 has been barely discussed through the years on the mailing list and specifically I haven't found documents, discussions about its birth. 

* May 1996 - draft of the specification http11 v3
* Jun 1996 - Cacheability of 410 responses [4]
* Mar 1998 - implementation/interop states [5]
* Sep 1998 - implementation status [6]
  4t 2y  7n| 4t 0y 14n| 2t 0y  6n|H 10.4.11 410 Gone
* Oct 1998 - What's new in HTTP 1.1 compared to HTTP 1.0 [7]

So I went off-list [8] :)

* Dec 1995 - Roy explained in his PostScript :) slides [9] 
  the new features of HTTP/1.1 (including 410 and DELETE)

The first definition of DELETE seems to be in Hypertext Transfer Protocol -- HTTP/1.0 March 8, 1995 [10]
======================================================================
    410 Gone

    The requested resource is no longer available at the server and no 
    forwarding address is known. This condition should be considered 
    permanent. Clients with link editing capabilities are encouraged to 
    delete references to the Request-URI (after user approval). If the 
    server does not know (or has no facility to determine) whether or 
    not the condition is permanent, the status code "404 Not Found" can 
    be used instead.

    The "410 Gone" response is primarily intended to assist the task of 
    web maintenance by notifying the recipient that the resource is 
    intentionally unavailable and that the server owners desire that 
    remote links to that resource be removed. Such an event is common 
    for limited-time, promotional services and for resources belonging 
    to individuals no longer working at the server's site. It is not 
    necessary to mark all permanently unavailable resources as "gone" 
    or to keep the mark for any length of time -- that is left to the 
    discretion of the server owner.
======================================================================
with a more practical paragraph than the current one. 
but a complete fail in my search for discussions around it.

[1]: http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/thread#msg51
[2]: http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/thread#msg53
[3]: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0036
[4]: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0469
[5]: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998JanApr/0508
[6]: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998SepDec/0065
[7]: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998SepDec/0093
[8]: http://ftp.ics.uci.edu/pub/ietf/http/
[9]: http://ftp.ics.uci.edu/pub/ietf/http/meetings/slides-dallas.ps
[10]: http://ftp.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v10-spec-00.txt

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 27 Aug 2011 18:17:18 +1000

Hi Karl,

> [1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.7

We can't break currently conformant implementations, unless there's a compelling security or interoperability issue. I don't see it here.

Cheers,

--
Mark Nottingham   http://www.mnot.net/