Es ist wirklich alles nur ein einfacher Fehler und das ; ist korrekt.
RFC 1867 war eine experimentelle Definition. Alle nachfolgenden Definitionen haben diesen Fehler korrigiert. Zum Beispiel:
Und schließlich ... gibt es auch eine offizielle Korrektur nach RFC 1867, um es zu machen Verwenden Sie das korrekte Trennzeichen.
Verlassen Sie sich auf die neueste RFC: 7231, Abschnitt 3.1.1.1 sagt:
%Vor%Dies lässt keinen Raum für Interpretationen oder benutzerdefinierte Formate.
Leider ist es nicht der erste Fall, den ich sehe, wenn mehrere RFCs miteinander in Konflikt stehen.
In diesem genauen Fall ist RFC 1049 explizit Cover Content-type header. RFC 2045 bezieht sich auf RFC 1049. Darüber hinaus RFC 2045 November 1996, so ist es die neueste.
Der gegenteilige Fall wird in RFC 1867 sehr kurz behandelt.
Also, ich schlage vor, Semikolon zu verwenden.
Beachten Sie, dass Ihre beiden widersprüchlichen Beispiele nicht wirklich widersprüchlich sind. Die erste, RFC-1867, definiert Erweiterungen für HTML. Die anderen beiden, RFC-1049 und RFC-2045, definieren beide Erweiterungen des Internet Mail-Protokolls.
Für eine REST-API würde ich wahrscheinlich mit RFC-1867 gehen, das im Hinblick auf HTML über HTTP entworfen wurde, im Gegensatz zu den anderen beiden, die mit RFC-822-basierten E-Mails über SMTP / POP / IMAP entworfen wurden im Hinterkopf.
Tags und Links rest content-type