wake-up-neo.com

Benutzerdefinierte HTTP-Header: Namenskonventionen

Einige unserer Benutzer haben uns gebeten, Daten zu ihrem Konto in die HTTP-Header von Anfragen, die wir an sie senden, oder sogar Antworten, die sie von unserer API erhalten, aufzunehmen . Wie lautet die allgemeine Konvention zum Hinzufügen benutzerdefinierter HTTP-Header in Bezug auf Benennung, Format ... usw.

Sie können auch jede intelligente Verwendung dieser Elemente, auf die Sie gestoßen sind, im Web veröffentlichen. Wir versuchen dies mit dem, was da draußen am besten ist, als Ziel umzusetzen :)

1018

Im Juni 2012 wurde die Ablehnung der Empfehlung zur Verwendung des Präfixes "X-" offiziell als RFC 6648 . Im Folgenden sind relevante Zitate aufgeführt:

3. Empfehlungen für die Erstellung neuer Parameter

...

  1. Stellen Sie den Parameternamen NICHT "X-" oder ähnliche Konstrukte voran.

4. Empfehlungen für Protokolldesigner

...

  1. Das Registrieren von Parametern mit einem "X-" Präfix oder ähnlichen Konstrukten DARF NICHT untersagt werden.

  2. Es darf NICHT festgelegt werden, dass ein Parameter mit einem "X-" Präfix oder ähnlichen Konstrukten als nicht standardisiert zu verstehen ist.

  3. NIEMALS festlegen, dass ein Parameter ohne "X-" Präfix oder ähnliche Konstrukte als standardisiert zu verstehen ist.

Beachten Sie, dass "SOLLTE NICHT" ("entmutigt") nicht dasselbe ist wie "MUSS NICHT" ("verboten"), siehe auch RFC 2119 für eine andere Spezifikation zu diesen Schlüsselwörtern. Mit anderen Worten, Sie können weiterhin Kopfzeilen mit dem Präfix "X-" verwenden, dies wird jedoch nicht empfohlen, und Sie können sie möglicherweise nicht so dokumentieren, als ob sie öffentlicher Standard wären.


Im Juni 2011 wurde das erste IETF-Entwurf unter veraltet ​​veröffentlicht, um zu empfehlen, das Präfix "X-" für nicht standardmäßige Header zu verwenden. Der Grund ist, dass, wenn nicht standardmäßige Header mit dem Präfix "X-" zum Standard werden, das Entfernen des Präfixes "X-" die Abwärtskompatibilität beeinträchtigt und Anwendungsprotokolle gezwungen werden, beide Namen zu unterstützen (z. B. _x-gzip_ & gzip sind jetzt gleichwertig). Die Empfehlung ist also, sie nur sinnvoll zu benennen , ohne das Präfix "X-".


Die Empfehlung ist war um ihren Namen mit "X-" zu beginnen. Z.B. X-Forwarded-For , X-Requested-With . Dies wird auch in a.o. Abschnitt 5 von RFC 2047 .

1073
BalusC

Die Frage muss noch einmal gelesen werden. Die tatsächlich gestellte Frage ist nicht mit den Herstellerpräfixen in CSS-Eigenschaften vergleichbar, bei denen eine Zukunftssicherung und das Nachdenken über Herstellerunterstützung und offizielle Standards angebracht sind. Die tatsächlich gestellte Frage ähnelt eher der Auswahl von URL-Abfrageparameternamen. Niemand sollte sich darum kümmern, was sie sind. Die Entfernung von Namen zu benutzerdefinierten Namen ist jedoch eine absolut gültige - und übliche und korrekte - Aufgabe.

Begründung:
Es handelt sich um Konventionen unter Entwicklern für benutzerdefinierte, anwendungsspezifische Header - ", die relevant sind to their account "- die nichts mit Anbietern, Standardisierungsgremien oder Protokollen zu tun haben, die von Dritten implementiert werden sollen, mit der Ausnahme, dass der betreffende Entwickler lediglich Header-Namen vermeiden muss, die möglicherweise vorhanden sind andere bestimmungsgemäße Verwendung durch Server, Proxies oder Clients. Aus diesem Grund sind die angegebenen Beispiele "X-Gzip/Gzip" und "X-Forwarded-For/Forwarded-For" umstritten. Die gestellte Frage bezieht sich auf Konventionen im Kontext einer privaten API, ähnlich den Namenskonventionen für URL-Abfrageparameter. Es ist eine Frage der Präferenz und des Namensabstands. Bedenken, dass "X-ClientDataFoo" von einem Proxy oder Anbieter ohne "X" unterstützt wird, sind offensichtlich falsch.

Das Präfix "X-" hat nichts Besonderes oder Magisches, aber es hilft, klar zu machen, dass es sich um einen benutzerdefinierten Header handelt. Tatsächlich unterstützen RFC-6648 ua die Verwendung eines "X" -Präfixes, da - da Anbieter von HTTP-Clients und -Servern das Präfix aufgeben - Ihre app-spezifischen, privaten API-, persönlichen Daten- Der Passing-Mechanismus wird durch die geringe Anzahl von offiziellen reservierten Header-Namen noch besser gegen Namensraum-Kollisionen isoliert. Meine persönliche Präferenz und Empfehlung ist es jedoch, einen Schritt weiter zu gehen und z. "X-ACME-ClientDataFoo" (wenn Ihre Widget-Firma "ACME" ist).

IMHO ist die IETF-Spezifikation nicht spezifisch genug, um die Frage des OP zu beantworten, da es nicht möglich ist, zwischen völlig unterschiedlichen Anwendungsfällen zu unterscheiden: App-Entwickler übergeben app-spezifische Zeichenfolgen an/von Client und Server. Die Spezifikation befasst sich nur mit der ersteren (A). Die Frage ist hier, ob es Konventionen für (B) gibt. Es gibt. Dabei werden die Parameter alphabetisch gruppiert und von den vielen normenrelevanten Überschriften des Typs (A) getrennt. Die Verwendung des Präfixes "X-" oder "X-ACME-" ist für (B) zweckmäßig und legitim und steht nicht in Konflikt mit (A). Je mehr Anbieter aufhören, "X-" für (A) zu verwenden, desto klarer werden die (B).

Beispiel:
Google (die in den verschiedenen Normungsgremien ein wenig Gewicht haben) gibt - ab heute, 20141102 in dieser geringfügigen Änderung zu meiner Antwort - derzeit mit "X-Mod-Pagespeed" die Version von an Ihr Apache-Modul ist an der Transformation einer bestimmten Antwort beteiligt. Schlägt jemand wirklich vor, dass Google "Mod-Pagespeed" ohne das "X-" verwenden und/oder die IETF bitten sollte, seine Verwendung zu segnen?

Zusammenfassung:
Wenn Sie in Ihrer App benutzerdefinierte HTTP-Header (als manchmal geeignete Alternative zu Cookies) verwenden, um Daten an Ihren/von Ihrem Server zu übertragen, und diese Header ausdrücklich NICHT für die Verwendung außerhalb von vorgesehen sind Im Kontext Ihrer Anwendung ist es eine sinnvolle und weit verbreitete Konvention, die Namen mit einem "X-" oder "X-FOO-" Präfix voneinander zu trennen.

498
cweekly

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, 'Kopfzeilen' wird die allgemeine Struktur einer Kopfzeile 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 Hauptpfeilern, Token und TEXT. Beide sind in Abschnitt 2.2, „Grundregeln“ definiert. Token ist:

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

Auf CHAR, CTL und Separatoren aufbauen:

   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>

Wobei LWS linearer weißer Raum ist, dessen Definition ich nicht reproduziere, und OCTET ist:

   OCTET          = <any 8-bit sequence of data>

Es gibt einen Hinweis zur Definition:

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 klar, dass der Kopfzeilenname aus einer Teilmenge von ASCII Zeichen bestehen muss - alphanumerische Zeichen, einige Satzzeichen, nicht viele sonst. Zweitens enthält die Definition eines Header-Werts nichts, was ihn auf ASCII einschränkt oder 8-Bit-Zeichen ausschließt: Er ist explizit besteht aus Oktetten, wobei nur Steuerzeichen gesperrt sind (beachten Sie, dass CR und LF als Steuerelemente gelten). Darüber hinaus impliziert der Kommentar zur TEXT-Produktion, dass die Oktette als in ISO-8859-1 interpretiert werden müssen und dass es einen Codierungsmechanismus gibt (der im Übrigen schrecklich ist), um Zeichen außerhalb dieser Codierung darzustellen.

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

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

61
Tom Anderson

Ändern oder besser gesagt Hinzufügen zusätzlicher HTTP-Header ist ein großartiges Tool zum Debuggen von Code, wenn nichts anderes.

Wenn eine URL-Anfrage eine Weiterleitung oder ein Bild zurückgibt, gibt es keine HTML- "Seite", auf die vorübergehend die Ergebnisse des Debug-Codes geschrieben werden können - zumindest keine, die in einem Browser sichtbar ist.

Ein Ansatz besteht darin, die Daten in eine lokale Protokolldatei zu schreiben und diese Datei später anzuzeigen. Eine andere Möglichkeit besteht darin, vorübergehend HTTP-Header hinzuzufügen, die die zu debuggenden Daten und Variablen widerspiegeln.

Ich füge regelmäßig zusätzliche HTTP-Header wie X-fubar-somevar: oder X-testing-someresult: hinzu, um die Dinge zu testen - und habe viele Fehler gefunden, die ansonsten sehr schwer aufzuspüren gewesen wären.

16
g1smd

Die Header-Feldnamenregistrierung ist in RFC3864 definiert, und bei "X-" gibt es nichts Besonderes.

Soweit ich das beurteilen kann, gibt es keine Richtlinien für private Header. Vermeiden Sie sie im Zweifelsfall. Oder werfen Sie einen Blick auf das HTTP Extension Framework ( RFC 2774 ).

Es wäre interessant, mehr über den Anwendungsfall zu erfahren. Warum können die Informationen nicht zum Nachrichtentext hinzugefügt werden?

16
Julian Reschke

RFC6648 empfiehlt, dass Sie davon ausgehen, dass Ihr benutzerdefinierter Header "standardisiert, öffentlich, allgemein bereitgestellt oder für mehrere Implementierungen verwendbar sein kann". Daher wird empfohlen, "X-" oder ähnliche Konstrukte nicht voranzustellen.

Es gibt jedoch eine Ausnahme: "Wenn es äußerst unwahrscheinlich ist, dass [Ihr Header] jemals standardisiert wird." Für solche "implementierungsspezifischen und privat genutzten" Header gibt der RFC an, dass ein Namespace wie ein Herstellerpräfix gerechtfertigt ist.

14
Edward Brey