Ответ 1
Если вы используете .NET 4.0, вы можете установить этот флаг в разделе system.web вашего web.config, и он будет разрешен:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
Я тестировал его, и он работает. Haack имеет объяснение.
Я использую бета-версию ASP.NET MVC, и я получаю ошибку HTTP 404 (ресурс не найден), когда я использую этот URL-адрес, который имеет "точку" в конце:
http://localhost:81/Title/Edit/Code1.
Если я удаляю точку в конце или точка находится где-то посередине, я не получаю ошибку.
Я пытался отлаживать, но я получаю сообщение об ошибке "System.Web.CachedPathData.GetConfigPathData(String configPath)" перед ProcessRequest в MvcHandler.
"Точка" не разрешена в конце URL-адреса? Или есть способ исправить определение маршрута для обработки этого URL?
В качестве примера: у меня есть таблица с именем Detail1 [Id (целое число), Code (string), Description (string)], которая имеет отношения FK с Master1 через столбец Id. Всякий раз, когда я выбираю запись Master1, я также выбираю запись Detail1, чтобы получить поле Код. Чтобы не делать это соединение каждый раз (так как обычно есть не только одна деталь, их больше одного), я предпочитаю не использовать столбец И, и я делаю код PK Detail1.
Но когда я избавляюсь от Id и использую Code как PK, тогда мои маршруты также начинают работать с полем Code, например: Detail1\Edit\Code1
Этот код может иметь что-либо в нем или в конце, включая DOT. Есть случаи, когда я могу запретить DOT в конце, но иногда он действительно имеет смысл.
И я также видел этот post, что маршруты могут быть очень гибкими, поэтому я не думал, что моя такая странная.
Итак, почему я делаю что-то такое нестандартное. Любые предложения?
А также почему так странно иметь DOT в конце URL-адреса?
Если вы используете .NET 4.0, вы можете установить этот флаг в разделе system.web вашего web.config, и он будет разрешен:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
Я тестировал его, и он работает. Haack имеет объяснение.
Это можно решить несколькими способами в каждой версии ASP.NET от версии 1.0 и выше. Я знаю это через два года после создания этой нити, но, в любом случае, здесь:
Создание настраиваемого обработчика ошибок или настройка настраиваемой страницы в IIS для перенаправления 404 не будут работать. Причина в том, что ASP.NET считает этот URL опасным. Внутренне в System.Web.Util.FileUtil
ASP.NET вызывает частный метод IsSuspiciousPhysicalPath
, который пытается сопоставить путь к (виртуальному, но законному) имени файла.
Когда полученный легализованный путь не равен исходному пути, обработка останавливается, а код ASP.NET возвращает 404 (он не запрашивает IIS или web.config для пользовательского 404, он возвращает один из них, который делает так сложно что-то сделать с этим).
Проводник Windows работает одинаково. Попробуйте создать имя файла, заканчивающееся на одну или несколько точек, т.е. test.txt.
. Вы увидите, что получившееся имя text.txt
.
Решение прост (как только вы это знаете, оно всегда есть). Перед отправкой этого сообщения 404 он выберет Application_PreSendRequestHeaders
, простое событие, которое вы можете зарегистрировать в Global.asax.cs
(или VB эквивалент). Следующий код вернет простой текст в браузер, но также возможен перенаправление или любой другой допустимый ответ.
protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpResponse response = this.Context.Response;
HttpRequest request = this.Context.Request;
if (request.RawUrl.EndsWith("."))
{
response.ClearContent();
response.StatusCode = 200;
response.StatusDescription = "OK";
response.SuppressContent = false;
response.ContentType = "text/plain";
response.Write("You have dot at the end of the url, this is allowed, but not by ASP.NET, but I caught you!");
response.End();
}
}
Примечание: этот код также работает, когда "aspx" не является частью URL-адреса. I.e., http://example.com/app/somepath. вызовет это событие. Также обратите внимание, что некоторые пути все равно не будут работать (заканчивая несколькими точками, с хэш-тегом или, например, < -sign, вызывает 400-Bad Request). Опять же, он работает для завершения цитаты, пробела + слэша или нескольких точек, разделенных пробелами.
Ну, в .NET 4.5 я исправил эту проблему, добавив "/" в конец URL-адреса.
Итак, в вашем случае это будет "http://localhost: 81/Title/Edit/Code1./". Это было единственное, что я сделал, мне не нужно было добавлять настройки httpRuntime.
добавить это в обработчики
<add name="ExtensionlessUrlHandler-Integrated-4.0-ForApi"
path="api/*"
verb="*"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
Возможно, http://localhost:81/Title/Edit/Code1%2E
будет работать.
Я избежал периода с шестнадцатеричным кодом ascii.
Почему у вас нет URI с точками?
Поскольку URI является запросом ресурса и исторический императив существует во всех соответствующих операционных системах, что символом точки является разделитель расширений. Последняя точка рассматривается как обозначение расширения файла, поэтому точка-завершение не имеет смысла.
Также стоит прочитать: