|
From: Duncan P. <no...@gi...> - 2026-09-16 07:32:44
|
Branch: refs/heads/dp-investigate-header-encoding-hack Home: https://github.com/eXist-db/exist Commit: 48cd9c0654c74ab985daaa84418c8a5f05358650 https://github.com/eXist-db/exist/commit/48cd9c0654c74ab985daaa84418c8a5f05358650 Author: duncdrum <d.p...@me...> Date: 2026-09-16 (Wed, 16 Sep 2026) Changed paths: M exist-core/src/main/java/org/exist/http/servlets/HttpResponseWrapper.java M exist-core/src/main/java/org/exist/xquery/functions/request/GetCookieValue.java M exist-core/src/test/java/org/exist/http/servlets/HttpResponseWrapperEncodingTest.java A exist-core/src/test/java/org/exist/xquery/functions/request/GetCookieValueDecodeTest.java Log Message: ----------- [bugfix] Avoid + / space ambiguity in cookie value percent-encoding URLEncoder/URLDecoder implement application/x-www-form-urlencoded, not RFC 3986 percent-encoding: they encode a space as '+' rather than '%20'. That collides with a literal '+' already present in a cookie value -- common in base64 payloads such as session tokens -- which would then be indistinguishably decoded back to a space. This affects not just foreign cookies but ones this instance itself set before this fix, since GetCookieValue#decode runs on every incoming cookie value regardless of who wrote it. Rewrite the encoded space to '%20' on write, and escape a literal '+' to '%2B' before decoding on read, removing the collision entirely ('+' is a valid cookie-octet byte per RFC 6265, so it never needed escaping). Also makes the header-encoding path's UTF-8 byte extraction explicit rather than relying on the platform default charset. Same RFC 3986-vs-form-urlencoded issue is being addressed for the xmldb: URI functions in #6451; pointed to from the inline docs as a candidate to share one implementation with. Co-Authored-By: Claude Sonnet 5 <no...@an...> To unsubscribe from these emails, change your notification settings at https://github.com/eXist-db/exist/settings/notifications |