241–250 of 361 posts
Earlier quoted context omitted.
OP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
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.
Wow this looks really great. Just tried it on my website[0], and page loads are pretty much instantaneous. However, it doesn't seem to work in Firefox 67 (Nightly). Does that mean it only works in Chrome? [0]: https://freshman.tech
Firefox has a bug that makes it redownload the page if that page is not cached.
Live demo on my website @ https://sysadmincasts.com/ Temporary added it in-line for testing. I was already in the sub 100ms level but this just puts it over the top! Also updated all admin add/edit/delete/toggle/logout links with "data-no-instant". Pretty easy. Open developer preview and watch the network tab. Pretty neat to watch it prefetch! Thanks for creating this! ps. Working on adding the license comment. I str…
Very impressive! Wonder if it'd be worth rerouting some of the paginated URLs like the episodes `?page=4` to `/page-4` or something like that. :shrug: - either way, looks like you had some fun optimizing it!
Earlier quoted context omitted.
Are you using an older browser? It sounds like your browser doesn’t support JS modules.
I... Never heard of JavaScript modules. I feel very out of date now. Anyway, yeah, I'm using the latest Firefox that still supports real addons, some of which aren't even possible to reimplement using the latest APIs in nightly.
Earlier quoted context omitted.
Indeed, breaking the web by misusing GET is not a good thing. By extension, keeping the web broken by not exposing this breakage is not a good thing either.
Like mentioned in another comment, if somebody used a GET http link to logout from a webpage, you would end up with a ton of surprised users. People who read articles by highlighting the text with the mouse would also probably hover over all of the links and would end up wasting bandwidth for no reason.
If you violate the standards, your website doesn't work. Who knew?
> People who read articles by highlighting the text with the mouse would also probably hover over all of the links and would end up wasting bandwidth for no reason.
"For no reason" is obviously wrong, making the web snappier is a reason.
Maybe browsers should only prefetch links on bloated websites since their owners clearly don't mind wasting bandwidth.
Earlier quoted context omitted.
OP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
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.
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).
Earlier quoted context omitted.
OP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
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.
How does this work on devices with touch screen? (My apologies if this question has already been raised)
(Your apology was rejected as it's clearly stated in the ultra short OP) It prefetches on touch event while a "click" is normally triggered by a touch release.
So now I can't even touch my screen without being taken somewhere else, because I don't know where all the active areas are.
Embedding via // without explicit SSL should probably be considered harmful or malicious as there is no reason to make such scripts available without SSL. Even if the end website is not using SSL users can still fetch your script securely.
There’s no security gain from going to HTTPS if the site is served over HTTP, but there’s a small speed hit.