On 27/08/2024 17:21, Christopher Schultz wrote:
Mark,
On 8/27/24 11:31, Mark Thomas wrote:
On 26/08/2024 15:14, Christopher Schultz wrote:
All,
On 8/16/24 11:25, Mark Thomas wrote:
On 16/08/2024 13:40, Tim Funk wrote:
How about missingEqualsCookie="allow | ignore"?
The proposed options were:
- ignore
- name
- value
By using [allow | ignore] instead of yes/no, it opens the door to
additional behaviors. (such as reject which triggers a http error)
Agreed.
I think maybe we should couple this new configuration attribute with
an enabled-by-default Valve (maybe only in 11/12, disabled-by-default
in 9/10) that detects empty cookie names and throws an exception
and/or returns a 400 response.
"ignore" should remove the cookie entirely and allow requests
containing these to be serviced. Using the "value" option with this
Valve enabled would cause a 400 response.
Or it could be worked-into an existing Valve/Filter such as the
HttpHeaderSecurityFilter or similar.
Or we could add a "reject" option to the configuration setting that
triggered an exception.
At what stage would this trigger an exception? Coudl the application
somehow catch that exception? I would think that a 400 response might
make more sense because what does "reject" mean to an application when
Tomcat is doing the rejecting? It wouldn't be much different than
"ignore" other than you have to tell the client it's being "rejected".
That suggests a 400 response to me.
Currently, when the cookie header is parsed. If session cookies are
enabled (they are by default) that parsing will occur during request
parsing which means any exception would be outside of the control of the
application and the client would see a 400 response.
If an application wants to control what to do here, it could use the
name option (or the value option if the Servlet spec is changed to allow
cookies with no name) and then check the cookies itself at an
appropriate point.
I don't think it is worth trying to refactor the cookie parsing so an
exception is thrown when the application requests the cookies.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
