Skip to content
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

Fix issue 453 #487

Merged
merged 3 commits into from
Dec 16, 2022
Merged

Fix issue 453 #487

merged 3 commits into from
Dec 16, 2022

Conversation

markt-asf
Copy link
Contributor

This is intended to fix #453

The first commit should be uncontroversial.

I suspect the second commit will require some discussion but, logically, I don't currently see any viable alternative. My reasoning for this is explained in #453 (comment)

@markt-asf
Copy link
Contributor Author

Forgot to update the copyright.

@markt-asf
Copy link
Contributor Author

I think this is worth an explicit review because of the second commit.

@@ -212,6 +212,10 @@ public interface ServletContext {
* application) security constraints. Care should be taken both when constructing the path (e.g. avoid unsanitized user
* provided data) and when using the result not to create a security vulnerability in the application.
*
* <p>
* The provided {@code path} parameter is canonicalized as per section 3.5.2 of the specification before being used to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like this. As far as I can see this would actually set a new precedent, as none of the other javadoc we have explicitly references a section of the spec (I could be wrong, but it seemed like all other references were to RFC's rather than the Servlet spec).

If we are going to do this I think we need to explicitly specify the version of the spec, as at some point the section number will change and we may forget to update the javadoc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out I was wrong, there is this:

* configured to not reject some suspicious sequences identified by 3.5.2, furthermore the container may be configured

This does not even specify which spec, let alone the version :-)

I really think that over time this will likely become outdated and rot, as these number can change if additional items are added, and it would be very easy to miss that they need to be updated, although I don't really have a good solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably come up with a very standard javadoc style for referencing a specific spec document and the section within it, so that we can easily find and update in future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this (with hyperlink to the right section in the HTML version of the spec):
Servlet 6.0, 3.5.2
We might need to tweak to working around the reference so that style works everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works for me

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me as well.

@markt-asf
Copy link
Contributor Author

Servlet specification references updated to agreed format and PR rebased.

@markt-asf markt-asf merged commit 78f5a09 into jakartaee:master Dec 16, 2022
@markt-asf markt-asf deleted the fix-issue-453 branch December 16, 2022 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clarify normalization of methods taking paths
3 participants