Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1271: headernames still case sensitive #1521

spring-issuemaster opened this Issue Oct 14, 2009 · 4 comments


None yet
1 participant

Arnljot Arntsen (Migrated from SEC-1271) said:

According to SEC-308 and SEC-315, this issue is supposedly fixed. But code is not in the distribution.

See attatched ntlm sample of how it failes in org.springframework.security.ui.ntlm.NtlmProcessingFilter.doFilterHttp line 328:
final String authMessage = request.getHeader("Authorization");

This returns null as the header is "authorization" as it's the normalized name Tomcat stores headers.

Arnljot Arntsen said:

As far as I can read from the current release candidate 3.0 and the stable release 2.0.8, the issue is present in both code trees.

Luke Taylor said:

The implementation of SavedRequest uses a case-insensitive comparator to store the headers and we have unit tests which show that header matching is case-insensitive.

If you are sure that headernames are still being compared in a case-insensitive manner, please provide clear evidence that this is the case.

NTLM is no longer supported in the codebase (it isn't in 3.0 RC1) and it seems more likely that this is a artifact of the NTLM implementation.

Arnljot Arntsen said:

Yes, it seems like a side effect of the NTLM filter. It tries to access the request, which is a SavedRequest inside a SavedRequestAwareWrapper, the new headers which has been set by the client(browser) is not available in the second request.

So this issue may be closed.

Luke Taylor said:

OK, thanks for confirming.

@spring-issuemaster spring-issuemaster added this to the 3.0.0.RC2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment