Каковы проблемы, связанные с обслуживанием страниц с помощью Content: application/xhtml + xml

В последнее время некоторые из моих новых веб-страниц (XHTML 1.1) настроены для создания регулярного выражения заголовка запроса Accept и отправки правильных заголовков HTTP-ответа, если пользовательский агент принимает XML (Firefox и Safari).

IE (или любой другой браузер, который его не принимает) просто получит простой тип контента text/html.

Будет ли у робота Google (или любого другого поискового робота) какие-либо проблемы с этим? Есть ли какие-то негативы для моего подхода, которые я просмотрел? Вы думаете, что этот сниффер заголовков сильно повлияет на производительность?

ОТВЕТЫ

Ответ 1

Я использую согласование содержимого для переключения между application/xhtml+xml и text/html так же, как вы описываете, не замечая проблем с поисковыми роботами. Строго говоря, вы должны учитывать значения q в заголовке accept, который указывает предпочтение пользовательского агента к каждому типу контента. Если пользовательский агент предпочитает принимать text/html, но будет принимать application/xhtml+xml в качестве альтернативы, то для обеспечения максимальной безопасности вы должны иметь страницу text/html.

Ответ 2

Одной из проблем с согласованием содержимого (и с обслуживанием разных контентов/заголовков для разных пользовательских агентов) являются прокси-серверы. Принимая во внимание следующее: Я столкнулся с этим назад в Netscape 4 дня и с тех пор скучаю по обрыву серверной стороны.

Пользователь A загружает вашу страницу с помощью Firefox и получает XHTML/XML Content-Type. Пользовательский ISP имеет прокси-сервер между пользователем и вашим сайтом, поэтому эта страница теперь кэшируется.

Пользователь B, тот же интернет-провайдер, запрашивает вашу страницу с помощью Internet Explorer. Сначала запрос попадает в прокси-сервер, прокси говорит: "Эй, у меня есть эта страница, вот она: application/xhtml + xml". Пользователю B предлагается загрузить файл (поскольку IE будет загружать все, что отправлено как application/xhtml + xml.

Вы можете обойти эту проблему, используя Vary Header, как описано в этом 456 Berea Street. Я также предполагаю, что прокси-серверы стали немного умнее об автоматическом обнаружении этих вещей.

Здесь, где CF, который является HTML/XHTML, начинает закрадываться. Когда вы используете согласование контента, чтобы обслуживать приложение /xhtml + xml одному набору пользовательских агентов, а text/html - другому набору пользовательских агентов, вы полагаетесь на все прокси-серверы между вашим сервером и вашими пользователями, чтобы быть хорошо себя вести.

Даже если все прокси-серверы в мире были достаточно умны, чтобы распознать заголовок Vary (это не так), вам все равно придется бороться с компьютерами-хранителями мира. В мире много умных, талантливых и преданных ИТ-специалистов. Есть еще не так умные люди, которые проводят свои дни с двойным щелчком по установкам установщика и думают, что "Интернет" - это синий E в своем меню. Неправильно сконфигурированный прокси-сервер все еще может неправильно кэшировать страницы и заголовки, оставляя вас не повезло.

Ответ 3

Единственная реальная проблема заключается в том, что браузеры будут отображать ошибки синтаксического анализа xml, если ваша страница содержит недопустимый код, в то время как в text/html они, по крайней мере, отображают что-то видимое.

На самом деле нет никакой пользы от отправки xml, если вы не хотите вставлять svg или обрабатываете XML-страницу.

Ответ 4

Проблема в том, что вам нужно ограничить разметку подмножеством как HTML, так и XHTML.

  • Вы не можете использовать функции XHTML (пространства имен, самозакрывающийся синтаксис для всех элементов), потому что они будут разбиты на HTML (например, <script/> будет закрыт до парсера text/html и убьет документ до следующего </script>).
  • Вы не можете использовать XML-сериализатор, потому что он может нарушить режим text/html (может использовать функции только для XML, упомянутые в предыдущей точке, может добавлять префикс тэга (иногда PHP DOM делает <default:h1>). <script> - это CDATA в HTML, но XML-сериализатор может выводить <script>if (a &amp;&amp; b)</script>).
  • Вы не можете использовать HTML-синтаксис (подразумеваемые теги, необязательные кавычки), потому что он не будет анализировать XML.
  • Рискует использовать инструменты HTML (включая большинство движков шаблонов), потому что они не заботятся о корректности (один unescaped & в href или <br> полностью разрушит XML и сделает ваш сайт работает только в IE!)

Я тестировал индексирование моего XML-сайта. Он был проиндексирован, хотя я использовал тип application/xml MIME, но он все равно анализировался как HTML (Google не индексировал текст, который находился в разделах <[CDATA[ ]]>).

Ответ 5

Так как IE не поддерживает xhtml как application/xhtml + xml, единственный способ получить поддержку кросс-браузера - использовать согласование контента. Согласно Web Благочестивому, содержание переговоров трудно из-за неправильного использования подстановочных знаков, когда веб-браузеры утверждают, что для поддержки каждого типа контента в существовании! Safari и Konquer поддерживают xhtml, но только подразумевают эту поддержку подстановочным знаком, в то время как IE не поддерживает ее, но также подразумевает поддержку.

W3C рекомендует только отправлять в XHTML браузеров, которые специально декларируют поддержку в HTTP Accept заголовок и игнорируя те браузеры, которые специально не декларировать поддержка. Однако обратите внимание, что заголовки не всегда надежны и, как известно, вызывают проблемы с кешированием. Даже если вы можете получить эту работу, нужно поддерживать две аналогичные, но разные версии - это боль.

Учитывая все эти проблемы, я сторонник предоставления xhtml промаха, когда ваши инструменты и библиотеки позволяют вам, конечно.