Dar Scott dsc at
Sat Jul 6 11:22:38 EDT 2019

Oh, RFC2616 is so twentieth century.

However, RFC7231 HTTP/1.1 agrees with the responses: 200 (OK), 202 (Accepted), or 204 (No Content).

It does have a couple examples that seems to indicate that DELETE might be used for logout, should one have imagination:

	DELETE might be used to remove a resource previously created with PUT (as I described).

	DELETE might be used to remove a resource previously created with a POST that returns a 201 (Created) status.

POST is favored for login, or so it seems from a quick search. POST is a command, an action. A wide range of status responses are allowed. So, perhaps the first login returns a 201 (Created) and subsequent logins either create new sessions (201) or return the same session (200). I think I saw a few cases where the responses were 200 and 404. Use of 200 with POST means that a proxy must have POST caching turned off or tweaked.

The 201 might return something like <>. The session key is part of the URL. Subsequent queries would use this as the base URL. DELETE would delete that.

This makes DELETE look more acceptable as logout.

However, this falls apart when we look at authentication. A token is usually not returned in a 201 as part of a session URL, but is more often a value that is returned in the authentication header for subsequent use of the session. It can also be returned as a cookie and subsequent requests use the cookie. In these scenarios, the semantic coherence of DELETE starts to fall apart.  

Also, login and logout are verbs. That seems to vote for POST for both.  

Yet, give me the protocol and I will work with it. I am not really as cranky as I claim.

Dar Scott
DarScott at

> On Jul 5, 2019, at 8:07 PM, Mark Wieder via use-livecode <use-livecode at> wrote:
> On 7/5/19 6:13 PM, Dar Scott Consulting via use-livecode wrote:
>> And an aside. Off topic.
>> I guess I am old-school. I know it is the fad, but using DELETE to logout seems goofy. Yeah, you can make a URL that looks like a session and you are deleting the session. But it seems that is like using HEAD to indicate what direction you are going or OPTIONS to set up options.
>> I know. I'm a cranky curmudgeon. I survive by recognizing that this is no longer HTTP, but a wolf in sheep's clothing to get past firewalls, a whole new protocol where we make it up as we go.
>> Now, given that, and I join the 21st century, DELETE returns a status code and an optional content. The status code is normally 204 (but maybe 205, which might be appropriate for log out) when no content is returned or 200 if content is returned. If the item is not there, the same applies, but perhaps 404 or 410 can also apply. If DELETE is used to mean logout, then the session is permanently gone and 410 on a repeat is appropriate. A 303 is OK (content is URL), but is probably handled by the underlying library.
>> Now, for proper symmetry, if DELETE is used to log out, then PUT must be used to log in. Both are idempotent, so logging in multiple times should be OK and logging out multiple times should be OK.  That is, a login returns 200 and a logout returns 204.  Every time.
>> I have not seen it implemented that way. We play the hands we are dealt.
> RFC 2616 describes only three possible responses to a DELETE verb:
> 200: the response includes an entity describing the status
> 202: the action has not yet been enacted
> 204: the action has been enacted but there is no status entity
> Idempotence appears to be optional. RFC2616 states that certain verbs "can" have this property. That said, not all servers or web apps support the DELETE verb - there's usually an option to enable/disable it.
> And I'm with you on the weirdness of using DELETE to log out. Bleah.
> But to Jacque's point, see this:
> <>
> -- 
> Mark Wieder
> ahsoftware at
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list