Ist Header ('Content-Type: text/plain'); überhaupt notwendig?

Question

Ich habe mit oder ohne diese Kopfinformation noch keinen Unterschied gesehen.

Answer 1

Definieren Sie "notwendig".

Es ist notwendig, wenn Sie den Browser wissen wollen, was die Art der Datei ist. PHP setzt den Header Content-Type automatisch auf text/html, wenn Sie ihn nicht überschreiben, damit Ihr Browser es als HTML-Datei behandelt, die kein HTML enthält. Wenn Ihre Ausgabe HTML enthält, sehen Sie sehr unterschiedliche Ergebnisse. Wenn Sie senden waren:

<b><i>test</i></b> 

ein Content-Type: text/html ausgeben würde:

Test

während Content-Type: text/plain ausgeben würde:

<b><i>test</i></b> 

TLDR Version: Wenn Sie wirklich nur Text ausgeben dann ist es nicht wirklich wichtig, aber es IS falsch.

Answer 2

PHP verwendet Content-Type "text/html" als Standard - was ziemlich ähnlich zu "text/plain" ist - und das erklärt, warum Sie keine Unterschiede sehen. text/plain ist erforderlich, wenn Sie Text so ausgeben möchten, wie er ist (einschließlich <> -symbols). Beispiele:

header("Content-Type: text/plain"); 
echo "<b>hello world</b>"; 
// Output: <b>hello world</b> 

header("Content-Type: text/html"); 
echo "<b>hello world</b>"; 
// Output: hello world 

Answer 3

nicht seine nicht so, hier ist Beispiel für die Unterstützung meiner Antwort ----> der klare Unterschied ist sichtbar, wenn Sie sich für HTTP-Komprimierung gehen, mit dem Sie die Daten zu komprimieren, während erlaubt Reisen von Server zu Client und der Typ dieser Daten wird automatisch als "gzip", die Browser, dass bowser bekam gezippte Daten und es hat upzip es, das ist ein Beispiel, wo Typ ist wirklich wichtig bei Bowser.

Answer 4

Wenn Sie den Inhaltstyp-Header festlegen, wirkt sich dies darauf aus, wie ein Webbrowser Ihren Inhalt behandelt. Wenn die meisten Mainstream-Webbrowser auf einen Inhaltstyp von text/plain stoßen, werden sie die rohe Textquelle im Browserfenster darstellen (im Gegensatz zur Quelle, die im HTML-Format gerendert wird). Es ist der Unterschied zwischen

<b>foo</b> 

oder

foo

Zusätzlich sehen, bei der Verwendung des XMLHttpRequest Objekt, Ihre Content-Type-Header beeinflusst, wie der Browser die zurückgegebenen Ergebnisse serialisiert . Vor der Übernahme von AJAX-Frameworks wie jQuery und Prototype war ein gängiges Problem mit AJAX-Antworten ein Content-Type, der auf text/html anstatt auf text/xml gesetzt wurde. Ähnliche Probleme würden wahrscheinlich auftreten, wenn der Inhaltstyp text/plain wäre.

Answer 5

Angenommen, Sie möchten eine Anfrage mit einem 204: Kein Inhalt HTTP-Status beantworten. Firefox wird sich mit "no element found" in der Konsole des Browsers beschweren. Dies ist ein Fehler in Firefox, der seit mehreren Jahren gemeldet, aber nie behoben wurde. Durch Senden eines Headers "Content-type: text/plain" können Sie diesen Fehler in Firefox verhindern.

Answer 6

Es ist sehr wichtig, dass Sie dem Browser mitteilen, welche Art von Daten Sie senden. Der Unterschied sollte offensichtlich sein. Versuchen Sie, die Ausgabe der folgenden PHP-Datei in Ihrem Browser anzuzeigen;

<?php 
header('Content-Type:text/html'); 
?> 
<p>Hello</p> 

Sie werden sehen:

hallo

(beachten Sie, dass Sie die gleichen Ergebnisse erhalten, wenn Sie die Kopfzeile in diesem Fall verpassen off - text/html ist Standard-PHP)

ändern sie text/plain

<?php 
header('Content-Type:text/plain'); 
?> 
<p>Hello</p> 

Sie werden sehen:

< p> Hallo </p>

Warum ist das wichtig? Wenn Sie so etwas wie die folgend in einem PHP-Skript, das zum Beispiel durch eine Ajax-Anforderung verwendet wird:

<?php 
header('Content-Type:text/html'); 
print "Your name is " . $_GET['name'] 

Jemand einen Link zu einer URL wie http://example.com/test.php?name=%3Cscript%20src=%22http://example.com/eviljs%22%3E%3C/script%3E auf ihrer Website platzieren kann, und wenn ein Benutzer klickt , sie haben alle ihre Informationen auf Ihrer Website allen zur Verfügung gestellt, die den Link aufstellen. Wenn Sie die Datei als text/plain bereitstellen, sind Sie in Sicherheit.

Beachten Sie, dass dies ein albernes Beispiel ist. Es ist wahrscheinlicher, dass das fehlerhafte Skript-Tag vom Angreifer einem Feld in der Datenbank oder mithilfe einer Formularübergabe hinzugefügt wird.