Доступен новый снапшот DataparkSearch Engine: dpsearch-4.54-2014-01-09. Основные отличия от предыдущего снапшота: Добавлены часовой и минутный тип лимитов Исправлена компиляции при указании ключа —without-aspell для configure Исправлено испольщование неиницализированного значения в некоторых случаях при использовании aspell Пример использования минутного лимита для ограничения поиска по времени (по умолчанию используется часовой тип лимита). В файле indexer.conf вместо команды […]

Можно переписать цитату Мэрилин Монро под тематику URL rewriting  :) «Если вы не можете справиться со мной, когда я в плохо выгляжу, то просто перепишите правила и получите 500 ошибку сервера.» Очень многие избегают настройки этих правил и на то есть причины, главная из них — одна ошибка и сайт не доступен полностью. При создании сайта […]

The post URL rewriting для чайников appeared first on Просто личный блог.

Можно переписать цитату Мэрилин Монро под тематику URL rewriting  :) «Если вы не можете справиться со мной, когда я в плохо выгляжу, то просто перепишите правила и получите 500 ошибку сервера.» Очень многие избегают настройки этих правил и на то есть причины, главная из них — одна ошибка и сайт не доступен полностью. При создании сайта […]

The post URL rewriting для чайников appeared first on Просто личный блог.

Ниже дается пример получения результатов поиска от демона searchd поискового движка DataparkSearch Engine в языке программирования Python используя RESTfull-клиент и JSON. Если вы используете Ubuntu Linux и у вас установлен интерпретатор Python, то никаких дополнительных пэкаджей для работы этого примера не требуется. Этот пример использует RESTful API, предоставляемый демоном searchd из DataparkSearch Engine и шаблон […]

Споры по этому вопросу — как правильно писать URL, со слешем на конце или без? — были и будут. Аргументация встречается разнообразная, и часто противоречива. А расплату за неверную запись универсального локатора ресурса (URL) воображают двух видов. Со стороны поисковиков — это якобы штрафные санкции за дубли страниц. С точки зрения производительности — якобы лишний редирект на страницу верной записи, автоматически генерируемый сервером.

Однако, разбирая технические спецификации стандартов Интернета, в частности документ " RFC 1738 — Uniform Resource Locators (URL)", приходится признать, что оба варианта записи адреса веб-ресурса формально правильные, и санкция за использование того или иного варианта — не более чем бзик поисковой системы или байки псевдо-SEO-шников.

С позиции лаконичности, более правильным представляется вариант «без слеша на конце» вне зависимости от того, адресует ли ваша ссылка «файл» на сервере или «папку», косвенное доказательство чему будет продемонстрировано ниже. Но и нет ни одного утверждения в документе, что иной вариант неверный или ссылается совсем на другой ресурс.

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


Читать дальше →