Тип содержимого для фрагментов HTML

Когда сервер отправляет ответ HTTP с документом HTML в теле, он обычно использует тип содержимого text/html. Должен ли тип контента отличаться, если ответ представляет собой фрагмент HTML?

Например, если запрос является AJAX от клиентского сценария, а весь текст ответа - <div><p>New text</p></div>, то ответ не является документом HTML. Должно ли приложение устанавливать для таких фрагментов тип контента, отличный от text/html? Если да, то?


http html ajax content-type
person Community    schedule 10.10.2013    source источник
comment
Статья по теме: daybarr.com/blog/ajax_content_type (другими словами: использование в качестве определенного mime -type может вызвать непреднамеренное изменение данных).   -  person Wrikken    schedule 10.10.2013
comment
@Wrikken, да, я читал это, но ему больше семи лет, и я не уверен, что такое искажение контента, которое описывает мистер Барр, происходит больше.   -  person    schedule 10.10.2013
comment
Что ж, у нас действительно есть намного больше мобильных устройств с медленным подключением, использующих «умные» прокси, сейчас приходит на ум Opera Turbo, но я понятия не имею, делают ли они что-нибудь еще, кроме сжатия. В любом случае, ответ на вопрос «Существует ли конкретный mime-тип для html-fragements - нет, и вы, вероятно, прекрасно обслуживаете его как любой тип text / *, хотя я предпочитаю ответы json с возможно встроенные html-строки, поэтому ответы могут делать другие вещи с небольшим количеством js-фреймворка на клиенте (информирование о тайм-ауте сеанса, перезагрузка всей страницы и т. д.)   -  person Wrikken    schedule 11.10.2013
comment
Я согласен с тем, что возвращать разметку в виде строк JSON - это хорошо. Ото, такие jQ-файлы, как $("#id").load(url), стали обычным явлением, но, по-видимому, для них нет соответствующего типа контента.   -  person    schedule 11.10.2013
comment
Для XHTML см. w3.org/TR/xml-fragment (Content-Type для Фрагмент XML совпадает с полным XML, это text/xml или в данном случае application/xhtml+xml). См. Также stackoverflow.com/a/2965701/287948   -  person Peter Krauss    schedule 10.05.2016

Ответы (3)


arrow_upward
6
arrow_downward

Что касается фрагментов документов XML / HTML, кроме xml-fragment, упомянутых в комментариях (теперь помечены как «больше не обслуживаются»), похоже, нет никаких явных официальных ссылок на фрагменты документа и заголовок типа контента. Однако следует учитывать некоторые моменты:

  • Спецификация xml-fragment рассматривает полные документы и фрагменты одинаково в отношении Content-Type.

  • В документации MDN по типам MIME не делается различия между полными документы и фрагменты (выделено добавлено):

Все содержимое HTML должно обслуживаться этим типом. Альтернативные типы MIME для XHTML (например, application / xml + html) в настоящее время в основном бесполезны (эти форматы унифицированы в HTML5).

  • Спецификация W3 8.4 Анализ фрагментов HTML явно описывает случаи обработки фрагмента документа HTML. Если синтаксический анализатор не завершится с ошибкой (обнаружит ошибку синтаксического анализатора), он предполагает, что указанная строка является HTML. Кроме того, недействительный / частичный HTML-код получен браузерами очень часто и отображается в максимально возможной степени (в отличие от правильного отказа).

    минимальные теги, необходимые для полного недействительного HTML-документа:

    • The DOCTYPE: <!DOCTYPE html> - declares the document mode, notably the spec requires them "for legacy reasons"
    • Название: <title>My Page</title>

    Пропуск этих обязательных элементов не меняет характера содержания. В практическом смысле <p>hello world все еще почти повсеместно интерпретируется как HTML, это просто недопустимый документ.

  • Стандарт RFC определяющий типы MIME явно определяет только text/plain, хотя RFC Content-Type спецификация заголовка ссылается на text/html. Очевидно, что это не дает четких указаний, но также не определяет никаких возможных альтернатив.

Учитывая единственную релевантную ссылку из W3, заявляет, что полные XML-документы и фрагменты обрабатываются одинаково (а HTML является подмножеством XML), алгоритм синтаксического анализа фрагментов W3 не делает различий (и предполагает, что он получает HTML), MDN не рекомендует использовать любых альтернативных заголовков, и нет широко распространенных (или действительно даже каких-либо заметных) альтернатив, использование text/html для фрагментов документа было бы очевидным выбором. Я не мог найти прецедента, чтобы предположить иное, и использование какого-либо настраиваемого типа MIME, вероятно, просто вызовет путаницу (или хуже).

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

person Greg Rozmarynowycz    schedule 16.01.2018

arrow_upward
3
arrow_downward

Это личное предпочтение. Если это только ваше приложение, это не имеет значения. Я бы оставил его text/html, потому что это все еще разметка HTML, даже если это не полный документ.

person Chloe    schedule 10.10.2013
comment
Да, ты прав. Если нет стандарта / spec / rfc, тогда это личное предпочтение. Печально, но обычный способ был бы отличным. - person guettli; 19.01.2018

arrow_upward
0
arrow_downward

Да, я тоже поправляюсь. Но совершенно нормально создавать свои собственные заголовки HTTP, если вы не полностью удовлетворены сопоставлением существующего заголовка с вашим вариантом использования. В этом направлении http://tools.ietf.org/html/rfc6648 "X- Заголовки на основе "теперь устарели. По сути, пока вы выбираете достаточно уникальный и значимый тип пантомимы, вы можете изобретать свой собственный. Но, как упомянул @Wrikken в своем комментарии, это может быть проблематично. Чтобы избежать всего этого, вы можете использовать text / html ИЛИ сделать это с помощью JSON, а не <div> способом. В идеальном и масштабируемом мире серверная сторона должна быть освобождена от создания HTML / DIV.

person gargkshitiz    schedule 19.01.2018