Express: Can I set a cookie path relative to application mount point?

[thw0rted]

When I call res.cookie(..., {path: "/foo"}), that path value is passed directly to the relevant HTTP response header. Any time I specify an absolute path like this, though, I limit where my application can be mounted. I have to either know that I'm always mounted under /foo, or compute this value for each request at runtime.

Is there any way to make the path relative to the application base? As far as I know, {path: "./foo"} is passed to the header literally, and RFC 6265 says that a Path that doesn't start with a leading slash is ignored (set to "default-path").

If such a syntax doesn't exist, would it be a reasonable feature to add?

[dougwilson]

Would using req.baseUrl (http://expressjs.com/en/4x/api.html#req.baseUrl) solve your issue?

[thw0rted]

That sounds about right. I thought maybe there was a way to compute that automatically, but I can use baseUrl for now.

ETA: apparently baseUrl won't include a trailing slash even if the app was mounted on a path with a trailing slash, so to make the cookie apply to all requests for the sub-application, you need {path: req.baseUrl + "/"}.

[dougwilson]

There may be, but not sure what your exact use case is. I understand a bit from what was written so far, but not enough if I were to try and write an app that did what you are trying to do, which is why I wasn't even sure if req.baseUrl would help.

[thw0rted]

The use case is that the app wants to set cookies for its own use and not have them passed to other request handlers. The problem is that if your top level application mounts fooApp at /foo, then later moves it to /sub/foo (or /newFoo), and FooApp hard-codes cookies to use {path: "/foo"}, your service will break and it won't be immediately obvious why.

My concern is that the current API defaults to coupling a service implementation detail (cookie path) with an integration detail (application mount path) in an opaque way, so I thought it would be nice to have an API that encourages reusable application design by getting rid of absolute paths.

[dougwilson]

Ok. I'm not sure if there is really robust way to do that, especially once you start to take into account fronting proxies in applications which do similar path re-writing and are outside of Express. If you have an ideal implementation that would be robust, you're always welcome to make a pull request with your idea! Effectively right now the API leaves it up to the user to construct the path in a way that makes sense for their set up (perhaps they need to take into account a x-original-url header or similar, they always want it to be / at the root, or whatever else).

[thw0rted]

That's a good point, though I would suggest that a fronting proxy (say, apache ProxyPass) should probably be rewriting the header, if that's an option, much the same way that ProxyPassReverse rewrites links on a page.

I was imagining a path option that either a) supported a relative syntax like ./whatever, or b) automatically rewrote the value to account for a non-root mountpath. On further consideration, (b) doesn't make sense because sometimes one app might want to set cookies exclusively for a different (sibling / ancestor) app, or at the root, or whatever -- absolute path values should stay that way, and the default should probably still be /. (a) would be some nice syntactic sugar on just using req.baseUrl to build the path yourself, though. If you think it's worth a PR I could put one together.

[dougwilson]

It really depends on if you think it is worth getting at all worked out as the pr owner :) I can tell you that even as the relative path thing it will need to take all possibilities into account as we have landed feature similar before and it just gets issues filed endlessly for different edge cases that are not supported, which is why I mentioned x-original-url because it was an issue when we used to do a similar thing for redirects that you are asking to be done with cookie and it greatly reduced our support burden by just removing it (like on cookie).

[Emuentes]

@thw0rted Do you feel that the question was addressed?

If so, would it be alright to close the issue?

Just thinking of keeping the issues list down to the items that still need to be addressed to maximize the value of the limited time the maintainers have to review issues.

[thw0rted]

In light of Doug's comments it's probably best to leave it as is, rather than try to foresee edge cases as he says. Feel free to close it, and if I have some time maybe I can put together a PR to add an example that covers this case to the docs.

[wesleytodd]

Hey @thw0rted, as the person who opened the issue you can close it. As @Emuentes graciously pointed out, the express maintainers are pretty resource constrained, so anything community members can do to reduce the load on us is helpful. Every little bit helps!