Когда сервер отправляет HTTP-ответ с HTML-документом в теле, он обычно использует тип содержимого text/html. Должен ли тип контента отличаться, если ответ является фрагментом HTML?
Например, если запрос является AJAX из клиентского скрипта, а весь тело ответа <div><p>New text</p></div> то ответ не является документом HTML. Должно ли приложение задавать тип контента для чего-то другого, кроме text/html для таких фрагментов? Если да, то?
Это личное предпочтение. Если это только ваше приложение, то это не имеет значения. Я бы сохранил его text/html потому что это все еще разметка HTML, даже если не полный документ.
Что касается фрагментов документа XML/HTML, отличных от xml-fragment упомянутого в комментариях (теперь обозначается как "больше не поддерживается"), не отображаются какие-либо явные официальные ссылки на фрагменты документа и заголовок типа содержимого, Однако некоторые моменты, которые следует учитывать:
Спецификация xml-фрагмента рассматривает полные документы и фрагменты одинаково в отношении Content-Type.
Документация MDN по типам MIME не делает различий между полными документами и фрагментами (выделено мной):
Все содержимое HTML должно быть подано с этим типом. Альтернативные типы MIME для XHTML (например, application/xml + html) в наши дни бесполезны (HTML5 унифицирует эти форматы).
Спецификация W3 8.4 Parsing HTML Fragments явно описывает случаи обработки фрагмента документа HTML. Если синтаксический анализатор не сработает (вызывает ошибку парсера), он предполагает, что указанная строка является HTML. Кроме того, недействительный/частичный HTML-код принимается браузерами чрезвычайно часто и отображается в максимально возможной степени (в отличие от неправильного отказа).
Минимальные теги, требуемые для полного документа с недействительным HTML:
<!DOCTYPE html> - объявляет режим документа, особенно спецификация требует их " по наследственным причинам ",<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 или отправить дополнительный пользовательский заголовок с вашего сервера (я не мог найти ссылок на какую-либо распространенную практику в отношении этого, и может просто запутайтесь с другими разработчиками).
Да, я также исправлю это. Но вполне нормально создавать собственные HTTP-заголовки, если вы не полностью удовлетворены отображением существующего в своем прецеденте. В этом направлении устаревшие заголовки http://tools.ietf.org/html/rfc6648 "X- теперь устарели. В принципе, до тех пор, пока вы выберете достаточно уникальный и осмысленный тип mime, вы можете придумать свои собственные. Но, как отметил в своем комментарии @Wrikken, это может быть проблематично. Поэтому, чтобы избежать всего этого, вы могли бы отказаться от text/html или сделать это с помощью JSON-способа, а не <div>. В идеальном и масштабируемом мире серверная сторона должна быть свободна от создания HTML/DIVs