On 23/09/2024 04:28, Igal Sapir wrote:
Hello,
The current implementation of getRequestId() is optimized for speed and
generates IDs that are unique to a running instance of Tomcat.
But most server configurations nowadays require uniqueness across the whole
system, and currently we do not offer that as:
1. Request IDs are only unique to a running Tomcat instance
2. Request IDs are reset to 0 each time Tomcat is restarted
3. Request IDs are sometimes generated by another system like a load
balancer or reverse proxy, and passed around via the HTTP header
"X-Request-Id"
I want to propose a patch that would:
1. Check for HTTP header "X-Request-Id" and if valid (e.g. does not attempt
SQL or XSS injection etc.) returns it
That is behaviour we'd typically place in a Valve or Filter. Possibly an
extension to the RemoteIp[Valve|Filter] ?
Rather than us validate it, I'd make processing it optional and the
admins responsibility to ensure it is trusted if they opt to process it.
2. Generates a URL-safe Base64-encoded UUID (22 CaSe sensitive characters)
How expensive is that process compared to the existing mechanism?
The value will be set to the requestId private variable to ensure
consistent return value for multiple calls on the same Request.
I have the code ready, but wanted to discuss the matter here first.
The Servlet spec requires only that the ID is unique for the lifetime of
the container.
How will this interact with ServletRequest.getRequestId() and the
associated methods?
Should we make the request ID generator a pluggable component? If so, of
what?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
