Найдено несколько директив Host — есть ответ « Вопросы и ответы

Вопросы и ответы

Топ за месяц Топ за год Облако тегов   Задать вопрос

seo yandex Яндекс СЕО внутренняя сео-оптимизация

mataleao, 584 просмотра

Почему Яндекс выдает мне такую ошибку при проверке robots.txt? Вроде бы он составлен правильно:

User-agent: Yandex
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: /xmlrpc.php
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /wp-content/uploads/2012/04/dogovor.doc
Disallow: /hip-young-woman
Disallow: /hello-world-2
Disallow: /hello-contact
Disallow: /wp-content/uploads/2012/04/license.pdf
Disallow: /feed
Disallow: */feed
Disallow: /*?*

Disallow: /*?
Disallow: /*. js$
Disallow: /*.inc$
Disallow: /*.css$
Disallow: /search/*/feed
Disallow: /search/*/*
Disallow: /tag/
Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml

User-agent: *
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /wp-content/uploads/2012/04/dogovor.doc
Disallow: /hip-young-woman
Disallow: /hello-world-2
Disallow: /hello-contact
Disallow: /wp-content/uploads/2012/04/license.pdf
Disallow: /wp-trackback
Disallow: /wp-feed
Disallow: /wp-comments
Disallow: */trackback
Disallow: */feed
Disallow: */comments
Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml

Ответы:

Роман Севко

Неправильно:
—
User-agent: Yandex
. ..
Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml

10 лет назад

Для ответа необходимо авторизироваться

RPI.su — самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.

Переезд сайта после отказа от директивы Host — Платон Щукин

Платон Щукин

12 марта 2018, 18:22

В свете отказа от директивы Host я бы хотел рассказать подробнее о рекомендациях по переезду сайта. Данные рекомендации предназначаются как для переезда на протокол https, так и для переезда на новое доменное имя, поскольку алгоритм будет совпадать.

Директива Host позволяла сохранить доступность старого сайта на период переезда, однако ее использование было также сопряжено с некоторыми неудобствами. Например, необходимо было проверять, что в директиве Host всех зеркал указан один и тот же сайт, иначе переезд мог произойти некоректно. В связи с этим было решено отказаться от использования директивы Host — теперь переезд будет выполняться только при помощи редиректа HTTP-301. Это также упростит совмещение переезда в Яндексе и других поисковых системах. Теперь для переезда я рекомендую следующее:

1. Добавьте новый домен в Вебмастер (в том числе сайт по протоколу HTTPS, если переезд выполняется на HTTPS) и убедитесь, что он не склеен в группу зеркал с другим сайтом. Если это так, воспользуйтесь инструментом «Отклейка зеркал», чтобы расклеить сайты. После окончания расклейки переходите ко второму пункту.

2. Настройте редирект 301 со страниц старого сайта на аналогичные страницы нового. При этом я рекомендую учитывать несколько важных моментов:

— сайты должны совпадать между собой структурно, поэтому страницы старого сайта должны выполнять редирект именно на аналогичные страницы нового сайта. Если же структура сайта при переезде изменилась, Вы можете установить редирект со страниц старого сайта на аналогичные страницы нового, а с них установить редирект на нужные адреса. Наши рекомендации по смене структуры сайта описаны в разделе Помощи.

— оба сайта должны быть доступны роботу. Проверьте, что в robots.txt обоих сайтов содержатся одинаковые правила, ведь если будут запрещены разные страницы, это может привести к различию контента. Если сайты используют один и тот же файл robots.txt, то файл sitemap лучше указать по адресу нового главного зеркала, так как после переезда индексироваться будет именно он.

— убедитесь, что большая часть страниц сайтов доступна и отвечает кодом HTTP-200 ОК или кодом редиректа 301. Если на доменах существенная доля страниц будет недоступна из-за кода ответа 404, это может помешать переезду. В таком случае недоступные страницы можно запретить к индексированию в файле robots.txt, чтобы робот-зеркальщик не посещал их при сверке контента.

3. Проверьте, что все зеркала в группе выполняют редирект на желаемое главное зеркало. Это также относиться к версиям «с www» или «без www».

Когда все необходимые настройки будут внесены, в панели Яндекс.Вебмастера старого адреса отправьте заявку на переезд сайта. Если заявка была успешно принята, значит, настройки выполнены корректно и сайты смогут склеиться. Процесс склейки был значительно ускорен и сейчас может занимать от нескольких дней до 3 недель. Замечу, что завершение переезда не означает, что все страницы сайта сразу попадут в поиск по адресу главного зеркала. Страницы неглавного зеркала будут участвовать в поиске какое-то время, пока аналогичные страницы главного зеркала не будут проиндексированы. Постепенно, по мере обхода нужного сайта, неглавное сможет пропасть из поиска.

Зачастую также возникает вопрос, почему в Яндекс.Вебмастере у неглавного зеркала большое число страниц в списке «Загруженных», и это число может даже увеличиваться, хотя в поиске страницы не появляются. В этом нет какой-либо ошибки: в список загруженных входят все страницы, ссылки на которые известны индексирующему роботу, поэтому данные о таких страницах вполне могут храниться в базе робота. Попадать в поиск такие страницы не будут, так как принадлежат неглавному зеркалу.

Не забудьте также, что для нового домена в Яндекс.Вебмастере необходимо добавить свой файл sitemap и установить региональность.

Все блоги сервисов© 2013–2022  «Яндекс»

Разделы конфигурации — Apache HTTP Server версии 2.4

Доступные языки:  en  | фр  | я | ко | tr 

Директивы в файлах конфигурации могут относиться к весь сервер, или они могут быть ограничены для применения только к определенным каталоги, файлы, хосты или URL-адреса. В этом документе описывается, как используйте контейнеры раздела конфигурации или файлы .htaccess изменить область действия других директив конфигурации.

• Типы конфигурации Контейнеры секций
• Файловая система, веб-пространство и логические выражения
• Виртуальные хосты
• Прокси
• Какие директивы разрешены?
• Как объединяются разделы

См. также

• Комментарии

Существует два основных типа контейнеров. Большинство контейнеров оценивается для каждого запроса. Прилагаемые директивы применяются только для тех запросов, которые соответствуют контейнерам. , и <ЕслиВерсия> контейнеры, с другой стороны, оцениваются только при запуске сервера и перезапустите. Если их условия истинны при запуске, то прилагаемые директивы будут применяться ко всем запросам. Если условия неверно, вложенные директивы будут игнорироваться.

Директива содержит директивы, которые будут применяться только в случае соответствующего параметр определяется в командной строке httpd . Например, при следующей конфигурации все запросы будут перенаправлены на другой сайт, только если сервер запущен с использованием

httpd -DClosedForNow :

 
    Перенаправить "/" "http://otherserver.example.com/"
 

директива очень похожа, за исключением того, что она содержит директивы, которые применяться только в том случае, если конкретный модуль доступен на сервере. Модуль должен быть либо статически скомпилирован на сервере, либо должен быть динамически скомпилирован, и его строка LoadModule должна быть раньше в конфигурационный файл. Эту директиву следует использовать только в том случае, если вам нужно ваш конфигурационный файл для работы вне зависимости от того, установлены ли определенные модули. установлены. Его не следует использовать для включения директив, которые вы хотите работать все время, потому что он может подавлять полезные сообщения об ошибках про отсутствующие модули.

В следующем примере директива MimeMagicFile будет применяется, только если mod_mime_magic доступен.

 
    MimeMagicFile "conf/magic"
 

очень похожа на и , за исключением того, что она содержит директивы, которые применяться только в том случае, если выполняется конкретная версия сервера. Этот модуль предназначен для использования в тестовых наборах и больших сетях, которые должны работать с разными версиями httpd и разными конфигурациями.

 <ЕслиВерсия >= 2.4>
    # это происходит только в версиях больше или
    # равно 2.4.0.
 

, и <ЕслиВерсия> могут применять отрицательные условия, предваряя их проверку знаком «!».

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

Наиболее часто используемые контейнеры разделов конфигурации — это те, которые изменяют конфигурацию определенных мест в файловая система или веб-пространство. Во-первых, важно понимать, разница между ними. Файловая система — это вид ваших дисков как видит ваша операционная система. Например, при установке по умолчанию Apache httpd находится в /usr/local/apache2 в Unix файловая система или "c:/Program Files/Apache Group/Apache2" в файловая система Windows. (Обратите внимание, что косая черта всегда должна быть используется в качестве разделителя пути в файлах конфигурации Apache httpd, даже для Windows.) Напротив, веб-пространство — это представление вашего сайта, предоставленное веб-сервером и видел клиент. Итак, путь /dir/ в веб-пространство соответствует пути

/usr/local/apache2/htdocs/dir/ в файловой системе установка Apache httpd по умолчанию в Unix. Веб-пространство не обязательно должно отображаться непосредственно на файловая система, так как веб-страницы могут генерироваться динамически из баз данных или других мест.

Контейнеры файловой системы

<Каталог> и <Файлы> директивы вместе с их регулярными выражениями контрагентов, применять директивы к части файловой системы. Директивы, заключенные в раздел , применяются к указанный каталог файловой системы и все его подкаталоги каталог (а также файлы в этих каталогах). Тот же эффект можно получить с помощью файлов .htaccess. Например, в После настройки индексы каталогов будут включены для /var/web/dir1 каталог и все подкаталоги.

 <Каталог "/var/web/dir1"> 
    Опции +Индексы
 

Директивы, заключенные в секцию , применяются к любому файлу с указанное имя, независимо от того, в каком каталоге оно находится. Так, например, следующие директивы конфигурации будут, при размещении в основном разделе конфигурационного файла, запретить доступ к любому файлу с именем private. html независимо того, где он находится.

 <Файлы "private.html">
    Требовать все отказано
 

Для адресации файлов, найденных в определенной части файловой системы, <Файлы> и <Каталог> разделов можно комбинировать. Например, следующая конфигурация будет запрещать доступ к /var/web/dir1/private.html , /var/web/dir1/subdir2/private.html , /var/web/dir1/subdir3/private.html и любой другой экземпляр из private.html найдено под

/вар/веб/каталог1/ каталог.

 <Каталог "/var/web/dir1">
    <Файлы "private.html">
        Требовать все отказано
    
 

Контейнеры веб-пространства

<Местоположение> директива и ее аналог регулярного выражения, на с другой стороны, изменить конфигурация контента в веб-пространстве. Например, следующее конфигурация запрещает доступ к любому URL-пути, начинающемуся с /private. В частности, это будет применяться к запросам на 9/частный»> Требовать все отказано

директива не должна иметь ничего общего с файловой системой. Например, в следующем примере показано, как сопоставить конкретный URL-адрес внутреннего обработчика HTTP-сервера Apache, предоставленный mod_status . Файл с именем server-status не должен существовать в файловая система.

 <Расположение "/сервер-статус">
    Статус сервера SetHandler
 

Перекрывающееся веб-пространство

Чтобы иметь два перекрывающихся URL-адреса, необходимо учитывать порядок, в котором оцениваются определенные разделы или директивы. За <Расположение> это будет:

 <Расположение "/foo">

<Расположение "/foo/bar">
 

es с другой стороны, отображаются наоборот:

 Псевдоним "/foo/bar" "/srv/www/uncommon/bar"
Псевдоним "/foo" "/srv/www/common/foo" 

То же самое верно для ПроксиПасс директивы:

 ProxyPass "/special-area" "http://special. example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On 

Подстановочные знаки и регулярные выражения

, <Файлы> и <Местоположение> каждая директива может использовать подстановочные знаки в стиле оболочки, как в fnmatch из стандартной библиотеки C. Персонаж «*» соответствует любой последовательности символов, «?» соответствует любому одиночному символу, и «[ seq ]» соответствует любому символу в seq . «/» символ не будет соответствовать ни одному подстановочному знаку; это должно быть указано явно.

Если требуется еще более гибкое согласование, каждый контейнер имеет аналог регулярного выражения (regex) , и , которые позволяют perl-совместимый обычные выражения использовать при выборе спичек. Но см. раздел ниже о слияние конфигурации, чтобы узнать, как изменится использование разделов регулярных выражений как применяются директивы.

Раздел подстановочных знаков, не содержащий регулярных выражений, который изменяет конфигурацию все пользовательские каталоги могут выглядеть следующим образом:

 
    Индексы опционов
 

Используя разделы регулярных выражений, мы можем запретить доступ ко многим типам файлов изображений. сразу:

 
    Требовать все отказано
 

Регулярные выражения, содержащие именованных групп и обратные ссылки добавляются в среду с соответствующее имя в верхнем регистре. Это позволяет элементам путей к файлам и URL-адреса, на которые можно ссылаться из выражений и модули вроде 9/]+)»> Требовать группу ldap «cn=%{env:MATCH_SITENAME},ou=combined,o=Example»

Логические выражения

директива изменяет конфигурацию в зависимости от условия, которое может быть выражается логическим выражением. Например, следующая конфигурация отказывает в доступе, если заголовок HTTP Referer не начинается с «http://www.example.com/».

 <Если "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
    Требовать все отказано
 

Что использовать Когда

Выбор между контейнерами файловой системы и контейнерами веб-пространства на самом деле довольно легко. При применении директив к объектам, которые находятся в файловой системе всегда используйте или . При применении директив к объектам которые не находятся в файловой системе (например, веб-страница, созданная из базу данных), используйте .

Важно никогда не использовать при попытке ограничить доступ к объектам в файловой системе. Это потому, что многие разные местоположения веб-пространства (URL) могут отображаться в одной и той же файловой системе. местоположение, что позволяет обойти ваши ограничения. Например, рассмотрим следующую конфигурацию:

 <Расположение "/каталог/">
    Требовать все отказано
 

Это прекрасно работает, если запрос http://yoursite.example.com/dir/ . Но что, если вы находитесь на файловая система без учета регистра? Тогда ваше ограничение может быть легко обойти запросом http://yoursite.example.com/DIR/ . Директива , в напротив, будет применяться к любому контенту, поданному из этого места, независимо от того, как это называется. (Исключение составляют ссылки файловой системы. Один и тот же каталог может быть размещен более чем в одной части файловая система с использованием символических ссылок. директива будет следовать за символическим ссылка без сброса имени пути. Поэтому для высшего уровня безопасности, символические ссылки должны быть отключены с соответствующими Опции директива.)

Если вы, возможно, думаете, что ничего из этого к вам не относится поскольку вы используете файловую систему с учетом регистра, помните, что многие другие способы сопоставления нескольких местоположений веб-пространства с одним и тем же расположение файловой системы. Поэтому вы всегда должны использовать файловую систему контейнеры, когда вы можете. Однако есть одно исключение из этого правило. Установка ограничений конфигурации в <Расположение Раздел "/"> совершенно безопасен, потому что этот раздел будет применяться ко всем запросам независимо от конкретного URL.

Вложение разделов

Некоторые типы разделов могут быть вложены в другие типы разделов. На одном рука, <Файлы> можно использовать внутри <Каталог> . На с другой стороны, может использоваться внутри , и разделов (но не внутри другого <Если> ). Регулярное выражение аналоги именованного раздела ведут себя одинаково.

Вложенные разделы объединяются после невложенных разделов того же типа.

<Виртуальный хост> container содержит директивы, применимые к конкретным хостам. Это полезно при обслуживании нескольких хостов с одной машины. с разной конфигурацией для каждого. Чтобы получить больше информации, см. документацию по виртуальному хосту.

<Прокси> и контейнеры применяют только вложенные директивы конфигурации на сайты, доступ к которым осуществляется через прокси-сервер mod_proxy которые соответствуют указанному URL. Например, следующая конфигурация позволит только подмножеству клиентов получить доступ к www.example.com веб-сайт, использующий прокси-сервер:

 <Прокси "http://www.example.com/*">
    Требуется хост yournetwork.example.com
 

Чтобы узнать, какие директивы разрешены в каких типах разделы конфигурации, проверьте контекст директивы. Все, что разрешено в <Каталог> разделы также синтаксически разрешены в , <Файлы> , <Соответствие файлов> , <Расположение> , <Соответствие местоположения> , <Прокси> , и разделы. Однако есть некоторые исключения:

• Директива AllowOverride работает только в разделы.
• FollowSymLinks и SymLinksIfOwnerMatch Параметры работают только в разделах или .htaccess файлов.
• Директива Options не может использоваться в и разделы.

Разделы конфигурации применяются в особом порядке. Так как это может иметь важные последствия для того, как директивы конфигурации интерпретируются, важно понимать, как это работает.

Порядок слияния:

1. <Каталог> (кроме регулярных выражений) и .htaccess делается одновременно (с .htaccess , если разрешено, переопределение <Каталог> )
2. (и <Каталог "~"> )
3. и выполнено одновременно
4. <Местоположение> и одновременно
5. <Если>

Несколько важных замечаний:

• Кроме , внутри каждой группы разделы обрабатываются в том порядке, в котором они появляются в файлах конфигурации. Например, запрос /foo/bar будет соответствовать <Расположение "/foo/bar"> и <Расположение "/foo"> (группа 4 в данном случае): оба раздела будут оцениваться но в том порядке, в котором они указаны в файлах конфигурации.
• <Каталог> (группа 1 выше) обрабатывается в порядке кратчайшего каталога компонент к самому длинному. Например, <Каталог "/var/web/dir"> будет обработан до <Каталог "/var/web/dir/subdir"> .
• Если кратно <Каталог> разделов применяются в тот же каталог, в котором они обрабатываются в файле конфигурации заказ.
• Конфигурации, включенные с помощью директивы Include , будут рассматриваться как они находились внутри включающего файла в месте расположения Включить директиву .
• разделов внутри разделов применяются после соответствующих секций снаружи определение виртуального хоста. Это позволяет виртуальным хостам переопределить конфигурацию основного сервера.
• Когда запрос обслуживается mod_proxy , <Прокси> контейнер занимает место контейнера в обработке заказ.

Технические примечания

На самом деле есть <Местоположение> / <Соответствие местоположению> последовательность, выполняемая непосредственно перед фазой перевода имени (где Псевдонимы и DocumentRoots используются для сопоставления URL-адресов с именами файлов). Результаты этого последовательность полностью отбрасываются после перевода завершенный.

Взаимосвязь между модулями и разделами конфигурации

Один вопрос, который часто возникает после прочтения разделов конфигурации слияние связано с тем, как и когда директивы конкретных модулей, таких как mod_rewrite обрабатываются. Ответ не тривиален и требует немного предыстории. Каждый модуль httpd управляет своей конфигурацией, и каждая его директива в httpd.conf указывает одну часть конфигурации в конкретном контексте. httpd не выполняет команду во время ее чтения.

Во время выполнения ядро ​​httpd перебирает определенные разделы конфигурации в порядке описанные выше, чтобы определить, какие из них применимы к текущему запросу. Когда первый раздел совпадает, это считается текущей конфигурацией для этого запроса. Если последующий раздел тоже совпадает, затем каждому модулю с директивой в любом из разделов предоставляется возможность объединить свою конфигурацию между двумя разделами. В результате получается третья конфигурация, и процесс продолжается до тех пор, пока не будут заполнены все разделы конфигурации. оцениваются.

После вышеуказанного шага начинается «настоящая» обработка HTTP-запроса: каждый модуль имеет шанс запуститься и выполнять любые задачи, которые им нравятся. Они могут получить свою окончательную объединенную конфигурацию из ядра. httpd, чтобы определить, как они должны действовать.

Пример может помочь визуализировать весь процесс. В следующей конфигурации используется Заголовок директива mod_headers установить определенный HTTP-заголовок. Какое значение будет установлено httpd в CustomHeaderName заголовок для запроса к /example/index.html ?

 <Каталог "/">
    Заголовок установить CustomHeaderName один
    <Соответствие файлов ".*">
        Набор заголовков CustomHeaderName три
    

<Каталог "/пример">
    Набор заголовков CustomHeaderName два
 

• Каталог «/» соответствует и начальная конфигурация для установки заголовка CustomHeaderName со значением создается один .
• Каталог «/example» соответствует, и поскольку mod_headers указывает в своем коде на переопределение в случае слияния, создается новая конфигурация для установки заголовка CustomHeaderName со значением two .
• FilesMatch «.*» совпадает, и возникает еще одна возможность слияния, в результате чего для заголовка CustomHeaderName устанавливается значение three .
• В конце концов, на следующих этапах обработки HTTP-запроса будет вызван mod_headers , и он получит конфигурацию для установки заголовка CustomHeaderName со значением three . mod_headers обычно использует эту конфигурацию для выполнения своей работы, а именно установки заголовка foo. Это не означает, что модуль не может выполнять более сложные действия, такие как отбрасывание директив, потому что они не нужны или устарели и т. д.

Это верно и для .htaccess, так как они имеют тот же приоритет, что и Каталог в порядке слияния. Важно понимать, что разделы конфигурации, такие как Directory и FilesMatch , несопоставимы с конкретными директивами модуля, такими как Header или RewriteRule , поскольку они работают на разных уровнях.

Некоторые полезные примеры

Ниже искусственный пример, показывающий порядок слияние. Предполагая, что все они применимы к запросу, директивы в этот пример будет применяться в порядке A > B > C > D > Д. 9.*б$»> С <Каталог "/a/b"> А

Для более конкретного примера рассмотрим следующее. Независимо от того любые ограничения доступа, помещенные в разделы , раздел будет оценивается последним и разрешает неограниченный доступ к серверу. В Другими словами, важен порядок слияния, так что будьте осторожны!

 <Расположение "/">
    Требовать все предоставленные

# Ой! Этот раздел  не будет иметь никакого эффекта
<Каталог "/">
    <ТребоватьВсе>
        Требовать все предоставленные
        Не требовать размещения badguy.example.com
    
 

Content-Security-Policy — HTTP | МДН

Заголовок ответа HTTP Content-Security-Policy позволяет администраторам веб-сайта для управления ресурсами, которые пользовательскому агенту разрешено загружать для данная страница. За некоторыми исключениями, политики в основном включают указание источников серверов и конечные точки сценария. Это помогает защититься от атак межсайтового скриптинга. (Межсайтовый_скриптинг).

Дополнительные сведения см. в вводной статье о политике безопасности содержимого (CSP).

Тип заголовка	Заголовок ответа
Запрещенное имя заголовка	нет

 Content-Security-Policy: ; <политика-директива>
 

где состоит из: <директива> <значение> без внутренней пунктуации.

Директивы выборки

Директивы выборки управляют местами, из которых могут быть загружены определенные типы ресурсов.

дочерний источник

Определяет допустимые источники для веб-воркеров и вложенных контекстов просмотра, загружаемых с использованием таких элементов, как <кадр> и