Проблема с URL-адресом, который заканчивается %20

У меня большая проблема. Есть устройства в прямом эфире, которые отправляют URL-адрес/обновления. Это опечатка разработчика для этих устройств. В журналах сервера это выглядит как "/updates +".

У меня есть модуль перезаписи ManageURL, который обрабатывает все запросы без расширения. Но этот запрос вызывает HttpException:

System.Web.HttpException:

System.Web.HttpException
   at System.Web.Util.FileUtil.CheckSuspiciousPhysicalPath(String physicalPath)
   at System.Web.HttpContext.ValidatePath()
   at System.Web.HttpApplication.ValidatePathExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Как я вижу в журналах, модуль перезаписи URL-адресов даже не получает этот URL-адрес, поэтому я не могу его исправить.

Есть ли способ обработать эти URL-адреса с помощью ASP.NET?

Ответ 1

Хорошо, это старый поток, но мне нравится добавлять работоспособное решение, которое работает для всех версий ASP.NET. Посмотрите этот ответ в соответствующем потоке. В основном это сводится к регистрации на событие PreSendRequestHeaders в global.asax.cs.

В качестве альтернативы, когда на ASP.NET 4.0 или выше, используйте <httpRuntime relaxedUrlToFileSystemMapping="true" /> в web.config.

Ответ 2

Согласно some, это находится в System.Web.dll:

internal static void CheckSuspiciousPhysicalPath(string physicalPath)
{
  if (((physicalPath != null) && (physicalPath.Length > 0))
    && (Path.GetFullPath(physicalPath) != physicalPath))
  {
    throw new HttpException(0x194, "");
  }
}

Я думаю, вы не можете изменить это, но не можете его отключить в настройках IIS? Конечно, это также отключит все другие проверки...: - (

Или напишите какой-нибудь фильтр ISAPI, который выполняется перед указанным выше кодом? По словам написания вашего собственного модуля, легко обрабатывать хакерство URI в ASP.NET.

Или, создать свою собственную страницу ошибок. На этой странице (как показано в ссылке на взломанный URI выше) найдите конкретный текст в exception.TargetSite.Name, например CheckSuspiciousPhysicalPath, и если он найден (или просто всегда), посмотрите current.Request.RawUrl или что-то в этом роде, очистить ошибку и перенаправить на исправленный URL?

Ответ 3

вы можете запустить URL-переписывание ISAPI, например IIRF.

Ответ 4

Если у вас есть доступ к коду, почему бы просто не проверить "+" в конце и удалить его?