Re: DELETE url

[J. Landman Gay via use-livecode]

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 
shorter one.


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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 6, 2019 10:24:32 AM Dar Scott via use-livecode 
 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
darsc...@darzlab.com

On Jul 5, 2019, at 8:07 PM, Mark Wieder via use-livecode 
 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
ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DELETE url

[Dar Scott via use-livecode]

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
darsc...@darzlab.com

> On Jul 5, 2019, at 8:07 PM, Mark Wieder via use-livecode 
>  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
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode