Wenn ein Server eine HTTP-Antwort mit einem HTML-Dokument im Hauptteil sendet, verwendet er normalerweise die text/html Inhaltstyp. Sollte der Inhaltstyp anders sein, wenn die Antwort ein HTML-Fragment ist?
Wenn die Anforderung beispielsweise AJAX von einem Clientskript ist und der gesamte Antworttext ist <div><p>New text</p></div> dann ist die Antwort kein HTML-Dokument. Sollte die Anwendung den Inhaltstyp auf etwas anderes als festlegen text/html für solche Fragmente? Wenn ja, was?
Greg Rozmarynowycz
In Bezug auf andere XML/HTML-Dokumentfragmente als die xml-fragment auf die in den Kommentaren verwiesen wird (jetzt als “nicht mehr gepflegt” gekennzeichnet), scheint es keine expliziten, offiziellen Verweise auf Dokumentfragmente und den Header des Inhaltstyps zu geben. Einige Punkte sind jedoch zu beachten:
Die XML-Fragment-Spezifikation behandelt vollständige Dokumente und Fragmente gleich in Bezug auf die Content-Type.
Die MDN-Dokumentation auf MIME-Typen unterscheidet nicht zwischen vollständigen Dokumenten und Fragmenten (Hervorhebung hinzugefügt):
Alle HTML-Inhalte sollte mit dieser Sorte serviert werden. Alternative MIME-Typen für XHTML (wie application/xml+html) sind heutzutage meist nutzlos (HTML5 hat diese Formate vereinheitlicht).
Die W3-Spezifikation 8.4 Parsen von HTML-Fragmenten legt ausdrücklich Fälle für den Umgang mit einem HTML-Dokumentfragment fest. Sofern der Parser nicht fehlschlägt (einen Parserfehler trifft), geht er davon aus, dass es sich bei der angegebenen Zeichenfolge um HTML handelt. Darüber hinaus wird extrem häufig ungültiger/teilweiser HTML-Code von Browsern empfangen und im größtmöglichen Umfang gerendert (im Gegensatz zu einem völligen Fehlschlag).
Die Mindest-Tags, die für ein vollständig ungültiges HTML-Dokument erforderlich sind, sind:
<!DOCTYPE html> – deklariert den Dokumentmodus, insbesondere die Spezifikation erfordert sie “aus erbrechtlichen Gründen“<title>My Page</title>Das Weglassen dieser erforderlichen Elemente ändert nichts an der Art des Inhalts. Im praktischen Sinne <p>hello world immer noch fast überall als HTML interpretiert wird, ist es einfach kein gültiges Dokument.
Der RFC-Standard Definieren von MIME-Typen nur explizit definiert text/plainObwohl die RFC Content-Type Kopfspez Verweise text/html. Dies gibt natürlich keine klare Orientierung, definiert aber auch keine möglichen Alternativen.
Da die einzige relevante Referenz von W3 besagt, dass vollständige XML-Dokumente und Fragmente gleich behandelt werden (und HTML eine Teilmenge von XML ist), macht der W3-Fragment-Parsing-Algorithmus keinen Unterschied (und geht davon aus, dass er HTML empfängt), MDN rät von der Verwendung ab aller alternativen Header, und es gibt keine allgemein akzeptierten (oder wirklich nennenswerten) Alternativen, die Verwendung text/html für Dokumentenfragmente wäre die klare Wahl. Ich konnte keinen Präzedenzfall finden, der etwas anderes vorschlagen könnte, und die Verwendung eines benutzerdefinierten MIME-Typs würde wahrscheinlich nur Verwirrung stiften (oder Schlimmeres).
Wenn Sie in Ihrer Anwendung wirklich zwischen vollständigen Dokumenten und Fragmenten unterscheiden möchten, können Sie sie in JSON umschließen oder einen zusätzlichen benutzerdefinierten Header von Ihrem Server senden (ich konnte diesbezüglich keine Hinweise auf eine gängige Praxis finden und möglicherweise nur verwirrend für andere Entwickler).
Es ist eine persönliche Vorliebe. Wenn es nur Ihre App ist, spielt es keine Rolle. Ich würde es behalten text/html weil es immer noch HTML-Markup ist, auch wenn es kein vollständiges Dokument ist.
Ja, du hast recht. Wenn es keinen Standard/Spezifikation/RFC gibt, dann ist es eine persönliche Präferenz. Schade, ein gemeinsamer Weg wäre toll.
– Güttli
19. Januar 2018 um 13:28 Uhr
gargkshiz
Ja, ich bin auch in der Klemme dafür. Es ist jedoch völlig in Ordnung, eigene HTTP-Header zu erstellen, wenn Sie mit der Zuordnung eines vorhandenen zu Ihrem Anwendungsfall nicht vollständig zufrieden sind. In diese Richtung, https://www.rfc-editor.org/rfc/rfc6648 “X-” basierte Header sind jetzt veraltet. Grundsätzlich steht es Ihnen frei, Ihren eigenen zu erfinden, solange Sie einen ausreichend einzigartigen und aussagekräftigen Mime-Typ wählen. Aber wie @Wrikken in seinem Kommentar erwähnte, könnte das problematisch sein. Um all dies zu vermeiden, können Sie auf text/html zurückgreifen ODER dies über eine JSON-Methode tun, und nicht <div> Weg. In einer idealen und skalierbaren Welt sollte die Serverseite frei von der Erstellung von HTMLs/DIVs bleiben
Verwandter Artikel: daybarr.com/blog/ajax_content_type (mit anderen Worten: Die Verwendung als bestimmter Mime-Typ kann zu unbeabsichtigten Änderungen von Daten führen).
– Wrikken
10. Oktober 2013 um 18:30 Uhr
@Wrikken, ja, ich habe das gelesen, aber es ist über 7 Jahre alt und ich bin mir nicht sicher, ob die Art von Inhaltsverstümmelung, die Mr. Barr beschreibt, noch vorkommt.
– Benutzer213154
10. Oktober 2013 um 19:36 Uhr
Nun, wir haben eine viel Heutzutage mehr mobile Geräte mit langsamen Verbindungen, die “intelligente” Proxys verwenden, kommt mir Opera Turbo in den Sinn, aber ich habe keine Ahnung, ob sie etwas anderes als Komprimieren tun. Wie auch immer, die Antwort auf “Gibt es eine Spezifisch mime-type for html-fragements” ist nein, und Sie können ihn wahrscheinlich wie einen beliebigen text/*-Typ verwenden, obwohl ich JSON-Antworten mit möglicherweise eingebetteten HTML-Strings bevorzuge, damit die Antworten andere Dinge mit a tun können wenig js-Framework auf dem Client (Meldung eines Session-Timeouts, Neuladen der gesamten Seite etc.)
– Wrikken
10. Oktober 2013 um 20:09 Uhr
Ich stimme zu, dass die Rückgabe von Markup als JSON-Strings nett ist. Otoh, jQ Sachen wie
$("#id").load(url)ist üblich geworden, aber es gibt anscheinend keinen entsprechenden Inhaltstyp dafür.– Benutzer213154
10. Oktober 2013 um 20:30 Uhr
Für XHTML siehe w3.org/TR/xml-fragment (der Inhaltstyp für XML-Fragment ist dasselbe wie vollständiges XML, ist
text/xmloder in diesem fallapplication/xhtml+xml). Siehe auch stackoverflow.com/a/2965701/287948– Peter Krauß
10. Mai 2016 um 19:17 Uhr