ASP. NET внезапно хочет косую черту

Question

В приложении ASP. NET у нас есть много (думаю, несколько десятков) классов контроллеров, таких как:

[RoutePrefix("some/thing/1.0")]
public class SomeController : ApiController
{
    [HttpGet]
    [Route("")]
    public string GetInfo()
    {
        return "hello world";
    }

    [HttpPut]
    [Route("")]
    public void StoreInfo(string info)
    {
        // ...
    }
}

Это работало нормально в течение нескольких недель, без каких-либо проблем. , Мы могли бы назвать эти конечные точки следующим образом:

GET https://myWebApp/client/some/thing/1.0

Теперь, со вчерашней ночной сборкой, это перестало работать. Внезапно мы можем получить доступ только к тем URL-адресам с конечным значением sh, то есть

GET https://myWebApp/client/some/thing/1.0/

Это относится и к параметризованным запросам:

GET https://myWebApp/client/some/thing/1.0?x=42

больше не работает, но

GET https://myWebApp/client/some/thing/1.0/?x=42

делает.

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

Более того, это определенно связано с некоторыми изменениями в нашем приложении: я мог воспроизвести проблему на своей локальной копии приложения точно после обновление моих двоичных файлов до тех, что были в вчерашней сборке. (Обратите внимание, что сегодня утром была создана другая сборка, и проблема все еще осталась. Итак, вчерашняя сборка не была каким-то образом повреждена; все, что изменилось, кажется постоянным.)

Что мог бы измениться, и где еще я мог бы go искать его?

Или, более активно спросить:

Где я могу изменить это поведение?

Answer 1

Мы нашли конкретную причину появления ошибки:

Был закомментирован вызов MapSignalR, и без него куда более старая, предположительно ошибочная настройка была похоронена где-то в приложении. Активировались конфигурационные файлы: A TransferRequestHandler, путь которого был указан как *. вместо просто *.

. Предположительно, SignalR каким-то образом перезаписывает этот параметр после инициализации, поэтому проблема никогда не всплывала для последней пары. лет.

Итак, явно: файл Web.config содержал следующую строку:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0"/>

Это должно было быть изменено на

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0"/>

для выпуска здесь описан go.

(К сожалению, это решение вызывает еще одну проблему .)