9 ms·

I've been testing it for the past 30 minutes or so and found that it doesn't cause the same problems that InstantClick did. (Which was javascript errors that w

by xpose2000 8y ago

I've been testing it for the past 30 minutes or so and found that it doesn't cause the same problems that InstantClick did. (Which was javascript errors that would randomly occur.) I'll limit it to a small subset of users to see if any errors are reported but there is a good chance this could go live for all logged in users. Maybe even all website visitors if all goes well. Seems to have no impact on any javascript, including ads. Pages do load faster, and I can see the prefetch working. Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover.

hn_throwaway_99 8y ago
> Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover. Logout links should never be GETs in the first place - they change states and should be POSTs.
- slim 8y ago
  POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
  - glacials 8y ago
    Idempotency is not the issue, the issue is that a user might hover over the logout link, not click it, then move on to the rest of the site and find they are logged out for no reason.
    - enedil 8y ago
      That's exactly the problem with idempotency.
      - winstonewert 8y ago
        actually, no. Idempotency means that you can safely do the same operation multiple times with the same effect as doing it once. That's a different issue than the no-side-effects rule which GET is supposed to follow.
    - leesalminen 8y ago
      Right, which is why the included library includes an HTML attribute to disable prefetch on a given link.
      - pbreit 8y ago
        OP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
        leesalminen 8y ago
        A logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
        hateful 8y ago
        I think this is the argument for PUT instead of POST, not GET instead of POST.
        abathur 8y ago
        Also: sometimes a site is misbehaving (for myself, or maybe for a user we're helping) and it's helpful to directly navigate to /logout just to know everyone is rowing in the same direction. Using a POST, especially if you're building through a framework that automatically applies CSRF to your forms, forecloses this possibility (unless you maintain a separate secret GET-supporting logout endpoint, I guess).
        Guest10928391 8y ago
        When I originally started my community site I used GET for logout. However, users started trolling each other by posting links to log people out. It wasn't easy to control, because a user could post a link to a completely different site, which would then redirect to the logout link. So, I switched to POST with CSRF and never had another issue.
  - Gaelan 8y ago
    Ok, so make it a form/button styled to look like a link.
  - deleted 8y ago
    [deleted]
  - nardi 8y ago
    Lots of people in this thread confusing “idempotent” with “safe” as specified in the HTTP RFC: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
    - kbirkeland 8y ago
      FWIW RFC 2616 was obsoleted by the newer HTTP/1.1 RFCs: https://tools.ietf.org/html/rfc7231#section-4.2 https://tools.ietf.org/html/rfc7231#section-4.2
      - amenod 8y ago
        Which still doesn't change GP's point though: > 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". (there's an exception listed too, but doesn't apply to logout) EDIT: I know of someone who made a backup of their wiki by simply doing a crawl - only to find out later that "delete this page" was implemented as links, and that the confirmation dialog only triggered if you had JS enabled. It was fun restoring the system.
        kbirkeland 8y ago
        I don't know why you think I'm contradicting them. I was just pointing out that there are newer RFCs. They also happen to have a stronger and more complete definition of safe methods.
ezequiel-garzon 8y ago
Thanks, how did you find out about data-no-instant tag?
- sgustard 8y ago
  https://instant.page/blacklist https://instant.page/blacklist

hn_throwaway_99 8y ago

> Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover. Logout links should never be GETs in the first place - they change states and should be POSTs.

slim 8y ago
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
- glacials 8y ago
  Idempotency is not the issue, the issue is that a user might hover over the logout link, not click it, then move on to the rest of the site and find they are logged out for no reason.
  - enedil 8y ago
    That's exactly the problem with idempotency.
    - winstonewert 8y ago
      actually, no. Idempotency means that you can safely do the same operation multiple times with the same effect as doing it once. That's a different issue than the no-side-effects rule which GET is supposed to follow.
  - leesalminen 8y ago
    Right, which is why the included library includes an HTML attribute to disable prefetch on a given link.
    - pbreit 8y ago
      OP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
      - leesalminen 8y ago
        A logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
        hateful 8y ago
        I think this is the argument for PUT instead of POST, not GET instead of POST.
        abathur 8y ago
        Also: sometimes a site is misbehaving (for myself, or maybe for a user we're helping) and it's helpful to directly navigate to /logout just to know everyone is rowing in the same direction. Using a POST, especially if you're building through a framework that automatically applies CSRF to your forms, forecloses this possibility (unless you maintain a separate secret GET-supporting logout endpoint, I guess).
        Guest10928391 8y ago
        When I originally started my community site I used GET for logout. However, users started trolling each other by posting links to log people out. It wasn't easy to control, because a user could post a link to a completely different site, which would then redirect to the logout link. So, I switched to POST with CSRF and never had another issue.
- Gaelan 8y ago
  Ok, so make it a form/button styled to look like a link.
- deleted 8y ago
  [deleted]
- nardi 8y ago
  Lots of people in this thread confusing “idempotent” with “safe” as specified in the HTTP RFC: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
  - kbirkeland 8y ago
    FWIW RFC 2616 was obsoleted by the newer HTTP/1.1 RFCs: https://tools.ietf.org/html/rfc7231#section-4.2 https://tools.ietf.org/html/rfc7231#section-4.2
    - amenod 8y ago
      Which still doesn't change GP's point though: > 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". (there's an exception listed too, but doesn't apply to logout) EDIT: I know of someone who made a backup of their wiki by simply doing a crawl - only to find out later that "delete this page" was implemented as links, and that the confirmation dialog only triggered if you had JS enabled. It was fun restoring the system.
      - kbirkeland 8y ago
        I don't know why you think I'm contradicting them. I was just pointing out that there are newer RFCs. They also happen to have a stronger and more complete definition of safe methods.

ezequiel-garzon 8y ago

Thanks, how did you find out about data-no-instant tag?

sgustard 8y ago
https://instant.page/blacklist https://instant.page/blacklist