J. Landman Gay
jacque at hyperactivesw.com
Sat Jul 6 13:22:14 EDT 2019
This has been a fascinating discussion and you guys have been very helpful.
Gotta thank Charles for the ready-made handler and Stephen for the even
I read Charles' first and told the Rails programmer that I could indeed
send DELETE but it would take some scripting I'd never used before so we'd
need to test. (Later I saw Stephen's.) She said "oh, never mind, it will
take me 5 minutes to turn it into a POST." So once again I have managed to
dodge the bullet and Dar should be happy as well. :-)
Please do carry on, I might even learn something.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 6, 2019 10:24:32 AM Dar Scott via use-livecode
<use-livecode at lists.runrev.com> wrote:
> 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
> <http://www.example.com/api/jj73koaiekdyu33/>. 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 darzLab.com
>> On Jul 5, 2019, at 8:07 PM, Mark Wieder via use-livecode
>> <use-livecode at lists.runrev.com> 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 gmail.com
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode