Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A heck of a wild bug chase

georgemauer.net

Post reply on HN
Print view View original

31–40 of 59 posts

Re: A heck of a wild bug chase

#31

Post by dzaima »

danparsonson wrote: post #28
dzaima wrote: post #19

Earlier quoted context omitted.

And it gives some baseline accessibility functionality. Sucks that there isn't any gerneral "I am clickable" element that neither has bad default click behavior, nor has its own likely-unfitting styling.

What's wrong with a button? You can make it look like an can't you?

https://stackoverflow.com/questions/1367409 has varying amounts of CSS for that, ranging from bad (i.e. more than one line, i.e. the bar to beat for people to automatically use it over ) to horrific.

Looks like the rough minimum is this:

    background: none;
    border: none;
    padding: 0;
    cursor: pointer;
    font: inherit;
And, given that some answers there have browser-specific additions, it looks like the spec doesn't have sane effective restrictions on what funky things browsers can do, thus essentially making the answer a "no, you cannot portably make a button look exactly like a link".

And no CSS I could find made the button content flow inline with surrounding text (I even went through all of the computed CSS in FF devtools and added the differing ones to the button), so it looks like the answer is "no" in practice too. (though, granted, for a good amount of link-buttons out there you'd probably want no mid-button breaking)

Certainly looks like it'd be simpler to make a act like a link, than a , at least. At which point you lose the implicit accessibility functionality.

Re: A heck of a wild bug chase

#32

Post by _a_a_a_ »

Ethee wrote: post #4
jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…

A book is always a good start.

Re: A heck of a wild bug chase

#33

Post by lloeki »

togakangaroo wrote: post #18
thedanbob wrote: post #12

Earlier quoted context omitted.

> There was no form submission, I'm not sure where you got that. There was also no POST. OP was saying the logout function should have been behind a form submission / POST.

Ah, yes, I mean, agree that would have been technically correct, but like I said, its just not how a lot of the web works. auth0-nextjs seems to react to `GET` by default (though it might also work with `POST` and you certainly can override things)

It's well beyond "technically correct", especially for the web. The "safe methods" section is quite explicit about that:

https://www.rfc-editor.org/rfc/rfc7231#section-4.2.1

https://www.rfc-editor.org/rfc/rfc9110#name-safe-methods

By electing to actionably mutate state on GET, one subscribes themselves to a world of hurt.

It is totally how the web works, both as defined by HTTP and in practice. Surely one can pile a dozen workarounds to circumvent the GET safety definition, but then it's just flat out simpler to have it be a POST or DELETE and work as intended.

That a lot of people are doing it a certain - broken - way certainly does not mean they are right.

Re: A heck of a wild bug chase

#34

Post by throw156754228 »

Ethee wrote: post #4
jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…

Follow the Ruby on Rails getting started guide and build a toy Rails web app. It has conventional http semantics baked in, you'll learn a lot.

Re: A heck of a wild bug chase

#36

Post by [deleted] »

dzaima wrote: post #31
danparsonson wrote: post #28

Earlier quoted context omitted.

What's wrong with a button? You can make it look like an can't you?

https://stackoverflow.com/questions/1367409 has varying amounts of CSS for that, ranging from bad (i.e. more than one line, i.e. the bar to beat for people to automatically use it over ) to horrific. Looks like the rough minimum is this: background: none; border: none; padding: 0; cursor: pointer; font: inherit; And, given that some answers there have browser-specific additions, it looks like the spec doesn't have sa…

[deleted]

Re: A heck of a wild bug chase

#37

Post by kaoD »

langsoul-com wrote: post #27

So would this simply work if the Link component from nextjs wasn't used?

Yes but the underlying problem would still be there, lurking for the future. If e.g. I had a browser extension to prefetch links (for faster navigation) the same issue would be present.

The problem is logging out on a GET request, as discussed in current top comment. It's just semantically incorrect and many tools will (correctly) assume GET requests don't have side-effects (in HTTP's terms, it's a safe method).

E.g. it's very easy to have a GET request cached by mistake (and I've seen some faulty proxies do that, completely ignoring the upstream cache-control).

This is not a problem on Next or its Link component. It's on op's code (and maybe auth0-nextjs allowing logout on GET requests).

Re: A heck of a wild bug chase

#38

Post by keybored »

togakangaroo wrote: post #9
jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Author of the post here, There was no form submission, I'm not sure where you got that. There was also no POST. Though yes, I agree that in the core HTTP semantic, you wouldn't want to change state on a GET and that should include not calling `Set-Cookie`. And yet the reality is that that nearly every application - and many popular libraries like auth0 - do in fact set and clear cookies on `GET`. The issue here was t…

> Also I asked claude to criticize the article as a web forum might before publishing, and this is definitely the tone it gave :D

Come on.

Re: A heck of a wild bug chase

#39

Post by culturedsystems »

togakangaroo wrote: post #9
jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Author of the post here, There was no form submission, I'm not sure where you got that. There was also no POST. Though yes, I agree that in the core HTTP semantic, you wouldn't want to change state on a GET and that should include not calling `Set-Cookie`. And yet the reality is that that nearly every application - and many popular libraries like auth0 - do in fact set and clear cookies on `GET`. The issue here was t…

"because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used"

I may be wrong, but I don't think using JavaScript vs using the standard HTML element to prefetch makes a difference here. I don't see anything in the HTML specs about preload or prefetch delaying cookie setting to sometime after the resource is actually loaded (although admittedly I find this bit of the spec somewhat hard to read, as it's dense with references to other parts of the spec). I tried it out, and, both Firefox and Chrome set the cookies for preloaded and prefetched links when the resource is loaded, even if the resource is never actually used.

Re: A heck of a wild bug chase

#40

Post by kaoD »

Ethee wrote: post #4
jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…

MDN, no matter how highly rated, is still insanely underrated.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

Also the many HTTP RFCs, this one in particular covers semantics:

https://www.rfc-editor.org/rfc/rfc9110.html

As the age old wisdom says... RTFM :P

HTTP is awesome, I'm in love with it. Beautiful piece of work.

Post reply on HN