Семантические URL-адреса с точками в .net

Я пытаюсь создать семантические URL-адреса для страниц поиска, но если кто-то использует поиск, завершенный точкой, движок .net возвращает 404.

Запрос даже не попадает в механизм маршрутизации, поэтому я думаю, что это связано с безопасностью или чем-то в этом роде.

Например, в этом случае также не работают маршруты stackoverflow: https://stackoverflow.com/questions.


person Jokin    schedule 16.11.2008    source источник
comment
Нужна дополнительная информация. Какую именно технологию .NET вы используете для маршрутизации? Этот ASP.NET MVC также похож на stackoverflow.com?   -  person BuddyJoe    schedule 17.11.2008
comment
нет, это замковая монорельсовая дорога, но это не важно, так как запрос не попадает в код фреймворка. Я видел эту ошибку на классических сайтах веб-форм, asp.net mvc, а также на монорельсовых. Это должно быть связано с веб-сервером, но я ничего не могу найти об этом в документе.   -  person Jokin    schedule 17.11.2008


Ответы (6)


Если вы используете .NET 4.0 и IIS 7+, вы можете установить этот флаг в разделе system.web вашего web.config, и это будет разрешено:

<httpRuntime relaxedUrlToFileSystemMapping="true" />

Я протестировал это, и он работает. У Haack есть объяснение по этому поводу.

person bkaid    schedule 22.08.2010
comment
@Roger требует iis7. Я добавил это к ответу. - person bkaid; 18.02.2012
comment
как это можно сделать в IIS ‹7? - person bobek; 13.04.2012
comment
Обновитесь до более новой версии Windows. - person bkaid; 13.04.2012
comment
Мне пришлось использовать это для дурацкого синтаксиса wikipedia / Special: в Roadkill wiki. Хансельман подробно описывает здесь: hanselman.com/blog/blog/blog/ - person Chris S; 10.11.2013
comment
он не работает для меня в IIS express (версия 8) и .NET 4.5 - person Orion Edwards; 17.06.2014
comment
У нас была аналогичная проблема (URL-адрес содержал идентификатор с точкой): /example/id/123.45 Добавив косую черту в конце URL-адреса, это сработало для нас: / example / id / 12345 / - person Marcel Studer; 09.03.2015

Все после "." - это расширение файла. Если это расширение не сопоставлено с ASP.NET, оно не будет передано обработчику ASP.NET. Вместо этого IIS ищет статический файл. Отсюда и 404. Если он ничего не добавляет (а это трудно понять), я предлагаю удалить его.

person dpurrington    schedule 30.11.2008
comment
Но это также происходит на веб-сервере Visual Studio, где все запросы отображаются на asp.net. Это должен быть предыдущий обработчик или мера безопасности. Даже запросы статических файлов проходят через мои обработчики. Но если в запросе есть ./ в любой позиции, это не так. - person Jokin; 01.12.2008
comment
Я не думаю, что вы можете сделать какие-либо разумные выводы из того, как ведет себя сервер разработки. Насколько нам известно, он знает об этой проблеме с IIS и делает все возможное, чтобы вести себя так же. В конце концов, это не имеет значения, потому что вы собираетесь развертывать с помощью IIS, а не Cassini. - person dpurrington; 01.12.2008

Когда конечный период не имеет значения (как в случае https://stackoverflow.com/questions/tagged/etc.) вы можете использовать модуль IIS URL Rewrite для удаления конечных точек.

Шаблон: ^(.*[^.])(\.+)$
Перезаписать URL: {R:1}

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

person Aaron Maenpaa    schedule 29.03.2010

Похоже, что IIS может не знать, как обрабатывать запрос с пустым расширением.

Щелкните правой кнопкой мыши на веб-сайте и выберите «Свойства». Щелкните «Конфигурация ...» на вкладке «Домашний каталог». Посмотрите на «Расширения приложений» и попробуйте добавить пустое расширение или расширение с подстановочными знаками.

person Robert Wagner    schedule 16.11.2008
comment
Я так не думаю, это также происходит на веб-сервере Visual Studio, где все расширения управляются обработчиком .net. в моем случае URL-адрес выглядит как search.com/search/search- term-with-dot./location.aspx - person Jokin; 17.11.2008
comment
Хм, если вы также получаете сообщение об ошибке в VS, вы уверены, что у вас нет игнорируемого маршрута, который попадает? - person Matt Mitchell; 17.11.2008
comment
во время отладки запрос не попадает в точку останова в механизме подпрограммы. Если вы видите ссылки, которые я разместил в комментарии к Стефану, обработка обоих запросов очень разная, один обрабатывается зарегистрированным обработчиком 404, а другой - обработчиком по умолчанию. - person Jokin; 17.11.2008

Вы не должны помещать точные поисковые запросы пользователей в такую ​​строку запроса ... вы должны их URLEncode. Это решит проблему.

person Timothy Khouri    schedule 30.11.2008
comment
точка является допустимым символом в URL-адресе, поэтому, если я закодирую что-то с точкой, оно останется прежним. - person Jokin; 01.12.2008
comment
не будет, взгляните на stackoverflow.com/questions/294495/ - person Jokin; 04.12.2008

В Windows имена файлов не могут заканчиваться на "." Я думаю, что все проблемы связаны с этим, т.е. IIS не знает, что с ним делать, поэтому он никогда не доходит до обработчика ошибок ASP.NET и обрабатывается страницей IIS 404 по умолчанию.

Большинство поисковых систем (в любом случае Google) исключают знаки препинания из запросов, и я думаю, что ваш тоже.

РЕДАКТИРОВАТЬ: он падает, потому что у него нет типа файла, даже сайт Microsoft падает, посмотрите http://www.microsoft.com/en/us/fallover., но вы можете изменить файлы ошибок по умолчанию (хранящиеся где-нибудь, например, C: \ WINDOWS \ help \ iisHelp \ common) или полностью изменить их.

Проверьте это: Настройка пользовательских сообщений об ошибках (IIS 6.0)

person inspite    schedule 30.11.2008
comment
Конечно, имена файлов могут оканчиваться на '.' в Windows. - person Terminus; 30.11.2008
comment
Неправда, и система маршрутизации в ASP.NET не имеет ничего общего с именами файлов. - person Jeff Putz; 06.01.2010