When a client sends a request that's routed to an XPages-type URL (XPage, Servlet, webapp, etc.) that contains an invalid Cookie header, the request dies long before getting to the page. I described one of these situations a while back, which has an existing (though inconvenient) workaround:
https://frostillic.us/blog/posts/2021/2/3/xpages-dealing-with-cookie-name-x-is-a-reserved-token-
However, there are other ways this can fail without a workaround. For example, certain poorly-made VPN/firewall products do a sort of man-in-the-middle attack on their users and inject a cookie named "domain", which Domino's ancient Servlet spec vetos immediately, leading to this:
java.lang.IllegalArgumentException: Cookie name "domain" is a reserved token
at javax.servlet.http.Cookie.<init>(Cookie.java:144)
at com.ibm.domino.xsp.bridge.http.servlet.XspCmdHttpServletRequest.parseCookieString(XspCmdHttpServletRequest.java:353)
at com.ibm.domino.xsp.bridge.http.servlet.XspCmdHttpServletRequest.getCookies(XspCmdHttpServletRequest.java:287)
at com.ibm.domino.xsp.bridge.http.servlet.XspCmdHttpServletRequest.readSessionId(XspCmdHttpServletRequest.java:189)
at com.ibm.domino.xsp.bridge.http.servlet.XspCmdHttpServletRequest.<init>(XspCmdHttpServletRequest.java:160)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:286)
While Domino it's wrong per se here, and the real problem is the VPN software, it'd still be good if Domino caught this exception and skipped the cookie rather than halting the entire request. As it is, anyone using this VPN can't read my blog, which is a true shame.
I have the same type of errors now and then on a public XPages application - very frustrating!