Hacker News Reader

Comment by NBJack | Hacker News Reader

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages.

For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now the cookie at /cart conflicts with the one at /cart/checkout because each page has its own cookie.

If you want cookies to be global, set them to / or leave out the path. If you want more fine-grained cookies, use a specific path. What's the problem? Currency is—in your example—clearly a site-wide setting. I think sites should make more of their hierarchical structure, not less.

If you leave out the path, it will default to the directory of the current URL, not /.

If not for this default behavior, it would have been much easier to manage global settings such as currency. Right now, all it takes is one cookie without a path to introduce inconsistency, only on some pages, in a way that's hard to reproduce.

Isn't that just the feature working as intended? Of course it is possible to introduce a bug by setting or not setting a cookie somewhere where it should/shouldn't be set.

I've never found a use for path-based cookies personally, but I'm not sure this is a particularly compelling example.

The typical example of a path-based cookie is the "remember my login name" feature, where you want the cookie with the user name only available on the login page. (And you cannot use session storage because you want it to work whilst logged out.)

You don't need to store multiple login names for seperate pages though, so why can't this just be a site wide cookie?

That would include the cookie with each request, which is inefficient. And potentially it also can get sent with requests to other subdomains, which may not be desirable from a security point of view (it could be cdn.example.com, owned by someone else)

For modern applications you’ll have better ways to maintain state. As shown they cause trouble in practice. Cookies should be used sparingly.

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

Server can store session state

Server side session state for more than authentication is way worse than "code smell."

It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!

You just described how the whole web operates. It works just fine.

Even if you want client side, we have better ways now than cookies.

We do, but only cookies are universally available. Plenty of unusual user-agents in the world, or people like me that browse with JS off by default.

I add some products in phone. Then I login to desktop later for modification and order. Cart is empty. That's engineering smell. A really bad one.

Thats nothing more than UX/UI.

> In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

- https://en.wikipedia.org/wiki/Code_smell

Wait, you can't shard on session ID?

And this is an ephemeral key-value store here, which is basically a best-case scenario from a performance standpoint. It's basically the last thing you're going to need to think about sharding, which is why session stores traditionally cohabitate(d) with web servers.

No, session storage doesn't get expensive fast. It's extraordinarily cheap unless you screw up the configuration very badly indeed (Apparently PHP still defaults to writing session data to disk?!)

Reply on news.ycombinator.com