Пользовательское поле в журнале IIS имеет - для значения для определенных путей

Я настроил следующее правило перезаписи в файле web.config приложения ASP.NET, размещенном в IIS:

    <rewrite>
        <rules>
            <rule name="setappname">
                <match url=".*" />
                <serverVariables>
                    <set name="CONTAINER_APP_NAME" value="desiredValue" />
                </serverVariables>
            </rule>
        </rules>
    </rewrite>

И в «applicationHost.config» у меня есть следующие фрагменты:

    <sites>
        <site name="mysite" id="1" serverAutoStart="true">
            <application path="/" applicationPool=".NET v4.5">
                <virtualDirectory path="/" physicalPath="c:\mysite" />
            </application>
            <bindings>
                <binding protocol="http" bindingInformation="*:80:" />
            </bindings>
            <logFile directory="c:\iislog" period="MaxSize" truncateSize="4294967295">
                <customFields>
                    <add logFieldName="x-forwarded-for" sourceName="X-Forwarded-For" sourceType="RequestHeader" />
                    <add logFieldName="container-app" sourceName="CONTAINER_APP_NAME" sourceType="ServerVariable" />
                </customFields>
            </logFile>
            <applicationDefaults preloadEnabled="true" />
        </site>
    </sites>

А ТАКЖЕ

<system.webServer>
    <rewrite>
        <allowedServerVariables>
            <add name="CONTAINER_APP_NAME" />
        </allowedServerVariables>
    </rewrite>
</system.webServer>

Это отлично работает (я вижу 2 настраиваемых поля в журналах), за исключением случаев, когда путь заканчивается на «/» (например: / или /APath/). В этих случаях значение поля container-app (с использованием переменной сервера) всегда равно "-". Например:

$ curl --silent --output /dev/null -H "X-Forwarded-For:10.3.2.12" http://localhost/APath/

Урожайность:

2019-12-02 20:47:32 172.29.152.165 GET /APath/ - 80 - 192.168.7.4 curl/7.67.0 - 200 0 0 121 10.3.2.12,+::1 -

Тогда как:

$ curl --silent --output /dev/null -H "X-Forwarded-For:10.3.2.12" http://localhost/home.aspx

Урожайность:

2019-12-02 20:50:17 172.29.152.165 GET /home.aspx - 80 - 192.168.7.4 curl/7.67.0 - 200 0 0 63 10.3.2.12,+::1 desiredValue

Я даже включил отслеживание неудачных запросов, чтобы увидеть, возможно, правило перезаписи не выбирает эти пути, но я могу подтвердить, что правило соответствует пути, а для переменной сервера задано желаемое значение.

Интересно, есть ли что-нибудь еще, что я могу попытаться устранить. Почему такие пути не регистрируются должным образом?


url-rewrite-module iis-10 iis-logs
person Amir Keibi    schedule 02.12.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я думаю, что нашел проблему и разместил ее здесь для других.

Глядя на трассировку невыполненных запросов, я вижу, что IIS создает дочерние запросы для документов каталогов по умолчанию (URI, оканчивающиеся на «/»). По-видимому, правила перезаписи не применяются к дочерним запросам (например: https://forums.iis.net/t/1152699.aspx).

Чтобы решить эту проблему, я создал правило перезаписи, чтобы преобразовать такие запросы в явные запросы к документам, чтобы другое правило перезаписи применялось на уровне основного процесса:

       <rewrite>
            <rules>
                <rule name="setExplictDoc">
                    <match url="(.*(APath)/$)" />
                    <action type="Rewrite" url="{R:0}Default.aspx" />
                </rule>
                <rule name="setappname">
                    <match url=".*" />
                    <serverVariables>
                        <set name="CONTAINER_APP_NAME" value="desiredValue" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>

Идея пришла из https://support.microsoft.com/en-ca/help/3050055/iis-digest-authentication-does-not-permit-pass-though-authentication-f

person Amir Keibi    schedule 02.12.2019
comment
Я прошу вас отметить сообщение как ответ, это поможет другим людям, которые сталкиваются с аналогичными проблемами. - person Jalpa Panchal; 04.12.2019