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

голоса
0

Я установил следующее правило перезаписи в «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

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

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

Задан 02/12/2019 в 23:58
источник пользователем
На других языках...                            


1 ответов

голоса
0

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

Глядя на неисправных Следы запроса, я могу видеть , что 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

Ответил 03/12/2019 в 01:16
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more