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.
Two questions here:
Why is it necessary to list "resource chain functionality" directly?
Since the first part of this JavaDoc says "if set to true, allows HTTP sessions to be ....", then it makes sense to reiterate this in the converse, so I'd suggest:
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.
Well this is why I suggested the developers clarify it...
The surprising behaviour is that this also controls non-Spring Security features. From experience, the resource chain (seemingly) randomly not working in a Spring project is the most common issue.
You could just make "sessions" an aside remark for the whole thing, but then it's more obvious that the method is badly named or there's a bug.
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 think that this method aligns with the servlet JavaDoc, which says for
HttpServletResponse#encodeURL
:The way I read this is that implementers of
HttpServletResponse
should add thejsessionid
, encoding it as necessary, but if nojsessionid
is to be added, leave the URL unchanged. I agree thatHttpServletResponse#encodeURL
is a bit of an odd name, given the JavaDoc.The servlet spec, which refers in 7.1.3 to the function of adding
jsessionid
as a request parameter as "URL Rewriting".Because of these, the method
enableSessionUrlRewriting
seems like a natural name, evoking that it is to make surejsessionid
is not managed as a request parameter.Maybe what I'm missing is a more detailed description of the problem you are seeing when setting this to
true
. What are you expecting the Servlet container to do with the URL that gets skipped becauseHttpServletResponse#encodeURL
is bypassed?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 problem is when it's
false
: #3087Other things (e.g. Spring's resource chain) use
encodeURL
to do other stuff.