-
Notifications
You must be signed in to change notification settings - Fork 2k
Issue #13670 - Returning ISE in all getParameter use cases outlined by Servlet 6.1 spec #13678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
joakime
wants to merge
4
commits into
jetty-12.1.x
Choose a base branch
from
fix/12.1.x/13670/servlet-getparameter-ise
base: jetty-12.1.x
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
981b522
Issue #13670 - Returning ISE in all getParameter use cases outlined b…
joakime 65fe54a
Removing now redundant test
joakime 8cbac3e
Excluding VirtualMachineError from ISE wrapping
joakime 28ad2c8
Excluding LinkageError from ISE wrapping
joakime File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I agree with this as the whole point of uncheck throwables is that that they do not need to be declared. The contract for getParameter has declared ISE as a politeness not as a binding contract. Specifically, I would not expect throwables like
OutOfMemoryErrororClassFormatErrorto be caught and wrapped as an ISE.The javadoc of this method specifically allows for other handling of exceptional cases:
So I read this as allowing other exception to be thrown .
The whole point of BadMessageException being a RuntimeException, is that it is unlikely to be caught by an application and flow back to Jetty, where it can be handled correctly.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At best I could be convinced to
catch(RuntimeException| Exception)and wrap as an ISE.... or better yet a custom list of exceptions that we know we throw if we detect the kinds of conditions the javadoc mentions that should be ISEs.Even then, I think we should have a compliance mode to determine if we wrap unchecked exceptions with ISE or not.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the conversation ..
The purpose of "Containers may provide container specific options to handle some or all of these errors in an alternative manner that may include not throwing an exception." is to allow optional "container configuration" to change behavior away from the servlet spec.
We don't have such a configuration right now.
So we default to Servlet Spec behavior. (what this PR is doing)
If we want to honor the "container specific options" then we need a boolean like
boolean containerSpecificGetParameterBehavior = false;which defaults to servlet spec behavior.Allowing users to turn on the "container configuration" for our behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gregw I can add a a configuration to ServletContextHandler to allow setting this behavior (as the spec states).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The javadoc uses the language "@throws IllegalStateException if parameter parsing is triggered and a problem is encountered parsing the parameters including, but not limited to: invalid percent (%nn) encoding; ..."
That's not a specific list of failures, but all failures, there's no specific list, no limiting to specific conditions, it's all conditions that would cause a failure in these
getParameter*()methods.That would introduce a new
ServletCompliancemode.But I feel that this isn't needed, as the javadoc is unambiguous in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added an exclusion for
java.lang.VirtualMachineErrorandjava.lang.LinkageError, but any larger exclusion list is just invalid IMO (this includesRuntimeExceptionandThrowablewhich have many recoverable non-fatal exceptions already)