https://bz.apache.org/bugzilla/show_bug.cgi?id=69921
--- Comment #2 from JunWoo Kim <[email protected]> --- Thank you for the clarification. I agree that accessing request-scoped objects outside their intended lifecycle (for example, from another thread after request completion) is an application bug and outside the servlet specification. My motivation for reporting this was not to dispute that position, but to share the operational and diagnostic impact of the current behavior. Since Request.getRequestURI() now has an observable side effect (via MessageBytes.toStringType() mutating the underlying parsing state), the resulting failure mode (such as intermittent 404 responses caused by a different parsing path) can be difficult to diagnose in real production environments. In particular, this kind of out-of-lifecycle access can be introduced indirectly (for example via Java agents, instrumentation, or framework-level context propagation), which can make the root cause non-obvious from the application code. Without requesting any behavioral change, I wanted to ask whether the team would consider the following non-breaking improvements: Documentation: adding a brief note in the Javadoc for Request.getRequestURI() (or related documentation) that it mutates internal parsing state and must not be called concurrently or outside the request lifecycle. Diagnostics: when request parsing follows an unexpected path due to prior internal state changes, optional and guarded diagnostic logging (even at DEBUG level) could help operators more quickly correlate intermittent 404 responses with unexpected request lifecycle access. We will address this on the application side by avoiding propagation of Request or RequestAttributes and by copying required values before launching background work. If the team does not feel that any documentation or diagnostic changes are appropriate, please feel free to close this issue. Thank you again for your time and for maintaining Tomcat. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
