ASP.Net: ошибка неверного запроса HTTP 400 при попытке обработать http://localhost:5957/http://yahoo.com

Question

Я пытаюсь создать что-то похожее на diggbar.

Я использую Visual Studio 2010 и сервер разработки Asp.

Однако я не могу заставить сервер разработки ASP обработать запрос, поскольку он содержит «http:» в пути. Я пытался создать HTTPModule для перезаписи URL в BeginRequest, но обработчик событий не вызывается, когда URL-адрес http://localhost:5957/http://yahoo.com. Обработчик события вызывается, если URL-адрес http://localhost:5957/http/yahoo.com

Подведем итог:

• http://localhost:5957/http/yahoo.com работает
• http://localhost:5957/http//yahoo.com не работает
• http://localhost:5957/http://yahoo.com не работает
• http://localhost:5957/http:/yahoo.com не работает

Есть идеи?

Answer 1

Я написал статью с помощью Стефана, которая объясняет, как это сделать:

Эксперименты с дураками: учет процентов, угловых скобок и других непослушных вещей в URL-адресе запроса ASP.NET/IIS

Answer 2

От Стефана из команды ASP.Net: http://forums.asp.net/p/1431148/3221542.aspx

В текущих версиях ASP.NET URL-адреса, содержащие такие символы, как двоеточие, будут отклонены как потенциальная угроза безопасности. Историческая причина этого заключается в том, что базовая файловая система NTFS поддерживает альтернативные потоки ресурсов, к которым можно обращаться с именами, такими как «yourfile.txt: hiddendata.txt». Блокировка символа двоеточия в Urls предотвращает случайную работу плохо написанных приложений с альтернативными потоками ресурсов.

В текущих версиях ASP.NET также существует ограничение, заключающееся в том, что входящие URL-адреса должны сопоставляться с файловой системой NTFS для определения данных управляемой конфигурации.

В ASP.NET 4 эти ограничения могут быть по желанию сняты. Однако эти изменения внесены в бета-версию 2 версии ASP.NET 4 - их нет в бета-версии 1. Мы опробовали URL-адрес, указанный ранее в этом сообщении на форуме, и подтвердили это в наших внутренних сборках ASP.NET 4 вы можете использовать этот стиль Url и обрабатывать его без ошибок 400.

-Stefan

Answer 3

От Стефана из команды ASP.Net

В следующем документе «Что нового», посвященном бета-версии 2, я извлек следующее:

ASP.NET 4 представляет новые параметры для расширения диапазона допустимых URL-адресов приложений. Самым простым и полезным изменением является то, что ASP.NET дает разработчикам возможность разрешать более длинные URL-адреса. Предыдущие версии ограничивали длину пути URL до 260 символов (ограничение пути к файлу NTFS). В ASP.NET 4 разработчики имеют возможность увеличить (или уменьшить, если захотят) этот предел в зависимости от своих приложений, используя два новых атрибута конфигурации httpRuntime:

Измените значение для "maxRequestPathLength", чтобы разрешить более длинные или более короткие пути URL (часть протокола Url sans, сервер и строка запроса). Измените значение для maxQueryStringLength, чтобы разрешить более длинные или короткие строки запроса. ASP.NET 4 также позволяет разработчикам настраивать набор символов, используемых проверками символов в URL-адресе ASP.NET. Когда ASP.NET находит недопустимый символ в части пути URL-адреса, он отклоняет запрос с ошибкой HTTP 400. В предыдущих версиях проверки символов Url были ограничены фиксированным набором символов. В ASP.NET 4 разработчики могут настраивать набор проверок символов, используя другой новый атрибут конфигурации httpRuntime:

По умолчанию атрибут «requestPathInvalidChars» содержит семь символов, которые считаются недействительными (знаки «меньше» и «больше», а также амперсанд кодируются, поскольку конфигурация представляет собой файл XML). Затем разработчики могут расширить или уменьшить набор недопустимых символов в соответствии с потребностями своего приложения. Обратите внимание, что ASP.NET 4 по-прежнему отклоняет любые пути URL-адресов, содержащие символы в диапазоне символов ASCII 0x00-0x1F, поскольку они считаются недопустимыми символами Url (RFC 2396 считает эти символы недопустимыми, а на серверах Windows, работающих под управлением IIS6 или выше, http. Драйвер устройства протокола sys также автоматически отклоняет URL-адреса с этими символами).

• Stefan

Answer 4

У меня была именно эта проблема при создании сокращающего URL для ASP.net. На всю жизнь я не мог закодировать двоеточие таким образом, чтобы ASP мог его принять, используя HttpUtility.UrlEncode или escape-(javascript) () на стороне клиента.

Мое решение, что делать с кодировкой Base64. Превращает все это в не спорные буквенно-цифровые числа. Затем вы декодируете на сервере. Я использовал эти функции .

Кроме того, я создал модуль HttpModule, который будет запускаться ведущим дефисом, поэтому я знаю, что обрабатывать последующий URL-адрес для декодирования. Пинг мне, если вы хотите получить более подробную информацию.

Answer 5

Я ответил на аналогичный вопрос здесь.

https://stackoverflow.com/a/12037000/134761

Обычно ASP.net принимает только закодированные символы, такие как двоеточие после знака вопроса. К счастью, ASP.net MVC автоматически отображает как / api / Persons / XXXX, так и / api / people? Id = xxxx в сопоставлении по умолчанию, так что в итоге я и сделал.

Answer 6

Быстрое решение для среды разработки:

• Измените свойства веб-проекта на «Использовать локальный сервер IIS» и установите флажок «Использовать IIS Express» (который сохраняет URL-адрес VS Dev Server).

• Добавьте следующий параметр в Web.config внутри <system.web>:

  <httpRuntime requestPathInvalidCharacters="" />
  

При производственном развертывании учитывайте соображения безопасности, упомянутые в других ответах.

Answer 7

Попробуйте HttpUtility.UrlPathEncode(url) - Документы MSDN

Answer 8

В статье базы знаний 826437 (http://support.microsoft.com/kb/826437) содержится ответ на ваш вопрос

1. Убедитесь, что на компьютере установлен Microsoft .NET 1.1 SP1
2. В разделе реестра HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET создать 32-битное значение DWORD VerificationCompatibility = 1
3. Перезагрузите IIS.

У меня это сработало (IIS 6, ASP.NET 4), возможно, у вас тоже будет работать

Answer 9

Я почти уверен, что вы могли бы сделать это с помощью IIS rewrite. Насколько мне известно, ASP.NET Development Server не может выполнить перезапись, но вы можете попробовать сделать это, используя переписывающее устройство IIS7 или, если у вас более ранняя версия, с помощью фильтра перезаписи IAPS ISAPI .

Answer 10

Это не сбой IIS, это сервер разработки ASP. Попробуйте выполнить развертывание в IIS и посмотрите, работает ли он.