Что касается фрагментов документа XML/HTML, отличных от xml-fragment, упомянутых в комментариях (теперь помеченных как «больше не поддерживаемых»), как представляется, не существует явных официальных ссылок на фрагменты документа и контент тип заголовка. Тем не менее, некоторые моменты, рассмотреть следующие вопросы:
XML-фрагмент-спецификации обрабатывает полные документы и фрагменты того же в отношении к Content-Type.
Документация MDN на MIME Types не делает различий между полными документами и фрагментами (акцент добавил):
Все HTML содержание должны быть поданы с этим типом. Альтернативные MIME типы для XHTML (например, application/xml + html) в основном бесполезны в настоящее время (HTML5 унифицировал эти форматы).
W3 спецификация 8.4 Parsing HTML Fragments явно выкладывает случаи для обработки фрагмента HTML документа. Если синтаксический анализатор не сработает (вызывает ошибку парсера), он предполагает, что указанная строка является HTML. Кроме того, недействительный/частичный HTML-код принимается браузерами чрезвычайно часто и отображается в максимально возможной степени (в отличие от неправильного отказа).
minimum tags required для полной пустоты HTML документа являются:
- тип документа:
<!DOCTYPE html> - заявляет режим документа, в частности, спецификация требует от них "for legacy reasons"
- Название:
<title>My Page</title>
Отсутствие необходимых элементов не изменяет характер содержимого. В практическом смысле, <p>hello world по-прежнему почти повсеместно интерпретируется как HTML, это просто не действительный документ.
Стандарт RFC defining MIME types только явно определяет text/plain, хотя RFC Content-Type header spec ссылки text/html. Это, очевидно, не дает четких указаний, но также не определяет возможных альтернатив.
Учитывая значение только справка из W3 утверждает полные XML документы и фрагменты будут обработаны одинаково (и HTML является подмножеством XML), алгоритм фрагмент разборе W3 не делает различия (предполагается, что это получение HTML), MDN советует не использовать любые альтернативные заголовки, и нет общепринятых (или действительно даже каких-либо заметных) альтернатив, использование text/html для фрагментов документа было бы ясным выбором. Я не мог найти прецедента, чтобы предлагать иное, и использование какого-либо пользовательского типа MIME, вероятно, просто вызовет путаницу (или, что еще хуже).
Если вы действительно хотели сделать различие в приложении между полными документами и фрагментами, вы можете обернуть его в JSON или отправить дополнительный пользовательский заголовок с вашего сервера (я не мог найти ссылок на какую-либо распространенную практику в отношении это, и может просто запутать других разработчиков).
Связанная статья: http://www.daybarr.com/blog/ajax_content_type (другими словами: выполнение определенного типа mime может вызывают непреднамеренные изменения данных). – Wrikken
@Wrikken, да, я читал это, но мне больше 7 лет, и я не уверен, что содержание, которое г-н Барр описывает, больше не существует. –
Ну, у нас на мобильном устройстве _lot_ больше мобильных устройств на медленных соединениях с использованием «умных» прокси в настоящее время, Opera Turbo приходит на ум, но я не знаю, делают ли они что-нибудь еще, а затем сжимают. В любом случае, ответ на «Есть ли какой-либо тип mime-типа для html-fragements» - нет, и вы, вероятно, прекрасно обслуживаете его как любой тип текста/*, хотя я предпочитаю json-ответы, возможно, встроенные html-строки , поэтому ответы могут делать другие вещи с небольшим количеством js-фреймворка на клиенте (информирование о тайм-ауте сеанса, перезагрузке всей страницы и т. д.). – Wrikken