Currently Dillo stores cookies by saving the domain, the subdomain flag and the path:

# HTTP Cookie File
# This is a generated file!  Do not edit.
# [domain  subdomains  path  secure  expiry_time  name  value]

127.0.0.1	FALSE	/	FALSE	1888888888	session	XXX

However, that cookie was generated from a service running on port 5555.

The cookie file generated by curl follows the same format as well, and doesn't include the port number (5555):

# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_127.0.0.1	FALSE	/	FALSE	1888888888	session	XXX

This causes curl to also send the cookie to another service running in another port, say 6666.

This behavior is what the RFC 6265 expects clients to follow:

For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

However this doesn't make sense as multiple services may be running in the same machine on different ports, which shouldn't be reading or writing cookies that belong to other services. Unfortunately the same behavior is being described in a new RFC intended to update RFC 6255.

Currently, we set the domain or subdomain in cookiesrc, which doesn't specify the port either.

A possible solution is to bind the cookies to the scheme, domain and port (what is commonly known as the origin) and only send the cookies corresponding to the same origin. We could keep the compatibility with the current cookiesrc syntax and assume that no port means all the ports.

If the port is specified, like:

DEFAULT DENY
127.0.0.1:5555 ACCEPT
127.0.0.1:6666 ACCEPT

Then we accept the cookies on those ports only.

Similarly, for the cookies.txt file, we can add the port for those cookies that are bound to an specific port:

127.0.0.1:5555	FALSE	/	FALSE	1888888888	session	XXX
127.0.0.1:6666	FALSE	/	FALSE	1888888888	session	YYY

If the port is not present, we continue with the current behavior that binds the cookie to all ports. The idea is to keep the compatibility with an existing cookies.txt file.

Chromium added support for binding cookies to the origin in 2021:

https://issues.chromium.org/issues/40165805