On 09/08/2023 14:45, ma...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new c880673cff Update Servlet API for parameter error handling changes
c880673cff is described below
commit c880673cffad6b8884c1d2464e5a736e852e7eeb
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Thu Jun 15 12:15:08 2023 +0100
Update Servlet API for parameter error handling changes
Hi all,
I have started work on implementing these changes but wanted to gather
feedback before I go much further with the implementation work.
The key question is how much control do we want to provide over the
behaviour if invalid parameters are encountered?
Question 1.
The default behavior will be to throw an exception. Do we want to use a
single exception type or do we want to use specialized exceptions for
each type of error? It is more (boilerplate) code but specialized
exceptions allow applications to identify what went wrong without having
to do things like parse error messages.
Question 2.
Do we want to support non-default behavior which, most likely, would be
to ignore the invalid parameter(s) and continue processing? Assuming we
do, do we want to make that configurable for each type of error or just
have a single "ignoreInvalidParameters" option?
Option 1.
My current implementation is using specialized exceptions and per error
type configuration although it is still in progress. I'm also logging
all invalid parameters at debug level.
Option 2.
This is creating quite a lot of plumbing. I am wondering, given that
this is essentially handling for invalid requests, whether it is worth
it. The alternative approach I have in mind is:
- specialized exceptions for each type of error
- log errors at debug level
- no options to allow invalid parameters
- wait and see if users request configuration options as they start to
migrate to Tomcat 11
At this point I am leaning towards option 2 while keeping the
implementation I have so far for option 1 in a branch in case we decide
to add it later.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org