3 ms·

Furthermore, links which appear to perform non-idempotent actions (voting) which are sent as GET requests seem kind of sketchy. Ever hear the horror story abou

by henning 19y ago

Furthermore, links which appear to perform non-idempotent actions (voting) which are sent as GET requests seem kind of sketchy. Ever hear the horror story about what happens when Google rolls through your CMS that has the "delete" button as a link?

deleted 19y ago
[deleted]
twism 19y ago
unless the search indexer has registered, logged in, and posting stories and comments, its a non-issue
- Locke 19y ago
  Yes, that's fine as long as your logged in users don't use some form of "web accelerator" that pre-fetches "delete" links. Using get instead of post for these kind of actions is just asking for trouble.
  - dfranke 19y ago
    I take the BOFH outlook on this: that problem is isomorphic to the problem of a user leaking his account credentials to a malicious third party and should be dealt with in the same manner.
  - twism 19y ago
    thats true. [adding to the TODOs for my web app. :sigh:]
    - zach 19y ago
      You can just add rel="nofollow" to those links, by the way. Edit: Or so I thought. I'm wrong. It turns out there's no standard for this, so who knows what you can do today. But practically, Google Web Accelerator doesn't prefetch links with a query string, at least currently. So Paul's voting links are A-OK with GWA. And that's the only one that you need to worry about, at least today.
      - twism 19y ago
        do all web accelerators obey that?
        SwellJoe 19y ago
        All the good ones follow specifications and good practices religiously. But I've never met a good one.
        deleted 19y ago
        [deleted]
        zach 19y ago
        Thanks for asking, I double-checked and there are of course not even any informal standards for web accelerators, apart from their common appeal to the HTTP 1.1 standard when the issue of link following safety comes up: http://webaccelerator.google.com/webmasterhelp.html#prefetch3 http://webaccelerator.google.com/webmasterhelp.html#prefetch... I've edited my post. Thanks for your reply.
  - zach 19y ago
    Using some form of "web accelerator" is asking for trouble. I consider Paul's method better than requiring Javascript to vote or making the voting links some wacky kind of button element. If HTML had a method="post" option on <a>'s then it would be no problem to always use the proper HTTP verb, but we have to satisfice with what we've got.
    - Locke 19y ago
      I, too, have often wished for the method attribute you describe. That said, if you're already using javascript (as news.YC is), I really don't see why you wouldn't make use of xhr. In which case you could submit the request as a post. Note: I haven't poked around enough to see if news.YC works without javascript. If they degrade gracefully, more power to them, and I can almost understand the decision to do it the way they have.
dfranke 19y ago
Voting and deletion are both idempotent, they just aren't side-effect free. The weaker condition of idempotence is all you need for GET, because it's sufficient for guaranteeing that caching won't break things. The solution to the problem with Google is to not let anonymous users delete pages irrevocably.
- ratsbane 19y ago
  That's a good distinction. I had to look up the HTTP 1.1 RFC, 2616 and read section 9.1.1 "Safe Methods" to note that while what you're saying is correct, the RFC does strongly discourage... well, here: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
  - deleted 19y ago
    [deleted]

by henning 19y ago

deleted 19y ago

[deleted]

twism 19y ago

unless the search indexer has registered, logged in, and posting stories and comments, its a non-issue

Locke 19y ago
Yes, that's fine as long as your logged in users don't use some form of "web accelerator" that pre-fetches "delete" links. Using get instead of post for these kind of actions is just asking for trouble.
- dfranke 19y ago
  I take the BOFH outlook on this: that problem is isomorphic to the problem of a user leaking his account credentials to a malicious third party and should be dealt with in the same manner.
- twism 19y ago
  thats true. [adding to the TODOs for my web app. :sigh:]
  - zach 19y ago
    You can just add rel="nofollow" to those links, by the way. Edit: Or so I thought. I'm wrong. It turns out there's no standard for this, so who knows what you can do today. But practically, Google Web Accelerator doesn't prefetch links with a query string, at least currently. So Paul's voting links are A-OK with GWA. And that's the only one that you need to worry about, at least today.
    - twism 19y ago
      do all web accelerators obey that?
      - SwellJoe 19y ago
        All the good ones follow specifications and good practices religiously. But I've never met a good one.
      - deleted 19y ago
        [deleted]
      - zach 19y ago
        Thanks for asking, I double-checked and there are of course not even any informal standards for web accelerators, apart from their common appeal to the HTTP 1.1 standard when the issue of link following safety comes up: http://webaccelerator.google.com/webmasterhelp.html#prefetch3 http://webaccelerator.google.com/webmasterhelp.html#prefetch... I've edited my post. Thanks for your reply.
- zach 19y ago
  Using some form of "web accelerator" is asking for trouble. I consider Paul's method better than requiring Javascript to vote or making the voting links some wacky kind of button element. If HTML had a method="post" option on <a>'s then it would be no problem to always use the proper HTTP verb, but we have to satisfice with what we've got.
  - Locke 19y ago
    I, too, have often wished for the method attribute you describe. That said, if you're already using javascript (as news.YC is), I really don't see why you wouldn't make use of xhr. In which case you could submit the request as a post. Note: I haven't poked around enough to see if news.YC works without javascript. If they degrade gracefully, more power to them, and I can almost understand the decision to do it the way they have.

dfranke 19y ago

Voting and deletion are both idempotent, they just aren't side-effect free. The weaker condition of idempotence is all you need for GET, because it's sufficient for guaranteeing that caching won't break things. The solution to the problem with Google is to not let anonymous users delete pages irrevocably.

ratsbane 19y ago
That's a good distinction. I had to look up the HTTP 1.1 RFC, 2616 and read section 9.1.1 "Safe Methods" to note that while what you're saying is correct, the RFC does strongly discourage... well, here: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
- deleted 19y ago
  [deleted]