Server variable value duplicated when IIS Default Document module invoked
Description
Environment
Windows Server 2012 R2, IIS 8.5
Windows Server 2019, IIS 10
Activity
Scott Cantor March 20, 2024 at 4:19 PM
I figured, but you shouldn’t need to restart IIS, the RequestMap is reloaded. But you have to wait a full request to trigger it, so you’re always seeing one version behind if you don’t reload again.
Bobby Lawrence March 20, 2024 at 4:05 PM
Jeez - sorry Scott. Please disregard. The “exportDuplicateValues” setting is working as anticipated with both variables and headers. I must have been forgetting to restart the IIS service (World Wide Web Publishing Service) during my testing and only restarting the Shibboleth Daemon. (palm-to-face)
Scott Cantor March 20, 2024 at 2:56 PM
Reviewing the history again, the previous investigations indicated that the code paths that just called SetHeader without reading the originals back was not causing any duplications (which was why the built-ins didn’t get dup’d, they never “appended” themselves).
Unless that’s changed, what you’re reporting screams “the setting isn’t false”, it would fit the behavior.
If the SetHeader code path had started resulting in duplication in IIS 11, it’s not obvious how that could affect only the attribute headers/variables. So I’m definitely skeptical.
I don’t think there’s any logging of what it does unfortunately to prove that it was honoring the setting being false.
Scott Cantor March 20, 2024 at 2:51 PM
Also, the method it’s calling to set the internal ones vs. the attribute ones is the same, so if previously existing values are implicated, then there would have to be dups of both (or neither).
Something is off somewhere.
Scott Cantor March 20, 2024 at 2:45 PM
Are you trying to use headers here or just server variables? I could more easily believe headers are broken than the variables.
We’ll reopen and test it, but if that’s true, it’s probably not possible to fix because physically we call a method to replace the existing variable or header and if they’re not doing that, that’s again an IIS bug (it may be accumulating > 1 and not replacing).
The original code when the setting is true pulls out the prevous variable value and appends, which is required to support aliasing of attributes, but it causes the duplicates. The branch when the setting is false doesn’t do that and only calls a “set” method at the end for each one after building a set of values for each one.
The following issue has been reproduced in Shibboleth SP iis7_shib.dll 3.2.2.2 and 3.2.3.2 (can’t reproduce in 3.2.1.0) running on Windows Server with IIS. This behavior was first observed on a 2012 R2 server running IIS 8.5. It has been reproduced on new Server 2019 servers running IIS 10. The issue appears to have been introduced in v3.2.2.
/secure/default.aspx
<% @ Page Language="C#" %><%Response.Write("Request[\"displayName\"]: " + Request["displayName"] + "<br>");%>Visiting the path below (which loads default.aspx via the IIS default document module) results in the attribute value appearing twice in the server variable (separated by a semicolon):
https://<domain name>/secure/
Request["displayName"]: Rick Sanchez;Rick Sanchez
Visiting default.aspx directly results in the expected value returned in the server variable:
https://<domain name>/secure/default.aspx
Request["displayName"]: Rick Sanchez