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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

В действительности отправка xml не дает никаких преимуществ, если вы не хотите встраивать svg или не выполняете обработку страницы в формате xml.

Answer 3

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

Answer 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 (включая большинство шаблонизаторов), потому что они не заботятся о правильной форме (один неэкранированный & в href или <br> полностью сломает XML и сделает ваш сайт появляется работает только в IE! )

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

Answer 5

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

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

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