request - Finden Sie heraus, HTTP-Methode in PHP

Während der Überprüfung

$_SERVER['REQUEST_METHOD']

scheint die offensichtliche Wahl zu sein, da einige der Leute sichere Alternativen für Superglobale befürworten ( Ist die Verwendung von Superglobals direkt gut oder schlecht in PHP? und ähnliche Fragen), kann man tatsächlich Autosanitisierung verwenden

filter_input( INPUT_SERVER, 'REQUEST_METHOD' )

(möglicherweise mit einigen zusätzlichen Filterschaltern, z. B. FILTER_SANITIZE_SPECIAL_CHARS ).

Natürlich, im regulären ( GET / POST ) Fall gibt es nichts zu sanieren, aber eine gute Angewohnheit ist immer noch eine gute Gewohnheit IMO.

http://php.net/manual/en/reserved.variables.server.php

http://php.net/manual/en/function.filter-input.php

Das Format für HTTP-Header ist in der HTTP-Spezifikation definiert. Ich werde über HTTP 1.1 sprechen, für das die Spezifikation RFC 2616 ist . In Abschnitt 4.2, 'Message Headers', ist die allgemeine Struktur eines Headers definiert:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

Diese Definition beruht auf zwei Hauptsäulen, Token und TEXT. Beide sind in Abschnitt 2.2 "Grundregeln" definiert. Token ist:

   token          = 1*<any CHAR except CTLs or separators>

Der Reihe nach ruht auf CHAR, CTL und Separatoren:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

TEXT ist:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

Wo LWS linearer Leerraum ist, dessen Definition ich nicht reproduzieren kann, und OCTET ist:

   OCTET          = <any 8-bit sequence of data>

Die Definition ist mit einem Hinweis versehen:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

Also, zwei Schlussfolgerungen. Erstens ist es klar, dass der Header- Name aus einer Teilmenge von ASCII-Zeichen bestehen muss - alphanumerische Zeichen, einige Interpunktionszeichen, nicht viel anderes. Zweitens gibt es in der Definition eines Header- Werts nichts, was ihn auf ASCII beschränkt oder 8-Bit-Zeichen ausschließt: Er besteht explizit aus Oktetts, wobei nur die Steuerzeichen gesperrt sind (beachten Sie, dass CR und LF als Steuerelemente gelten). Des Weiteren impliziert der Kommentar zur TEXT-Produktion, dass die Oktetts als in ISO-8859-1 befindlich zu interpretieren sind, und dass es einen Codiermechanismus gibt (der übrigens schrecklich ist), um Zeichen außerhalb dieser Codierung darzustellen.

Um insbesondere auf @BalusC zu reagieren, ist es ziemlich klar, dass Header-Werte laut Spezifikation in ISO-8859-1 sind. Ich habe High-8859-1-Zeichen (speziell einige Akzentvokale, wie sie in Französisch verwendet werden) in einem Header von Tomcat gesendet und sie von Firefox korrekt interpretiert, so dass dies in gewissem Maße sowohl in der Praxis als auch in der Theorie funktioniert (Obwohl dies ein Location-Header war, der eine URL enthält und diese Zeichen in URLs nicht zulässig sind, war dies tatsächlich illegal, aber unter einer anderen Regel!).

Das heißt, ich würde mich nicht darauf verlassen, dass ISO-8859-1 auf allen Servern, Proxies und Clients funktioniert, also würde ich mich bei der defensiven Programmierung an ASCII halten.