Header-parsing-Fehler nach upgrade von Jetty 9.3

Ich habe ein Problem wenn ich mein jetty-Distribution von 9.2 auf 9.3. Unter 9.2 meine app funktioniert einwandfrei, jedoch beim ausführen die gleichen war-Datei und anschließen von dem gleichen client bekomme ich folgende Fehlermeldungen beim ausführen unter 9.3:

015-08-30 14:55:32.174:WARN:oejh.HttpParser:qtp1100439041-12: Illegal character 0x20 in state=HEADER_IN_NAME for buffer HeapByteBuffer@26dab36[p=62,l=654,c=8192,r=592]={POST /api/v1/time...0.1:8080\r\nKey <<<Info Header: ...erica/Toronto"}>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}

2015-08-30 14:55:32.175:WARN:oejh.HttpParser:qtp1100439041-12: bad HTTP parsed: 400 Illegal character 0x20 for HttpChannelOverHttp@6765bf81{r=0,c=false,a=IDLE,uri=- }

Von dem, was ich verstehe, es ist ein unzulässiges Zeichen in der überschrift, aber warum wird eine version, die diesen Fehler auslösen und der andere nicht?

Bin ich auch mit Apache httpclient 4.4.1 Daten zu senden.

InformationsquelleAutor andy9775 | 2015-08-30
  1. 19

    Upgrade von Jetty 9.2 9.3 gemeint, die Sie eingegeben, in der neuen Welt der HTTP/1.1-aktualisierte Spezifikationen und rfcs, und neue HTTP/2-Anforderungen, einschließlich änderungen an der HTTP/1.1-unterstützt HTTP/2 upgrade (h2c).

    Steg 9.2 gefolgt RFC2616 (Jetzt Veraltet durch: RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235 und Aktualisiert durch: RFC2817, RFC5785, RFC6266, RFC6585)

    Steg 9.3 folgt die updates auf den alten (von 1999!) RFC2616 spec. Viele Dinge, die gültig waren in der Vergangenheit nicht mehr gültig sind. Wir haben auch sank die Unterstützung für HTTP/0.9 in Steg 9.3

    Gibt es viele Teile von HTTP/1.1 wurden aufgeräumt zu nutzen, die aktualisiert RFCs, einige von Ihnen haben könnte, Biss Sie.

    Blick auf die spec, RFC7230: Abschnitt 3.2 - Header-Felder, sehen Sie die header-Feld deklariert als...

     header-field   = field-name ":" OWS field-value OWS

 field-name     = token
 field-value    = *( field-content / obs-fold )
 field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
 field-vchar    = VCHAR / obs-text

 obs-fold       = CRLF 1*( SP / HTAB )
                ; obsolete line folding
                ; see Section 3.2.4

    mit token definiert in RFC7230: Anhang B - Gesammelt ABNF als ...

    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
        "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar

    was bedeutet, dass Ihre " " (Raum) in "Info Header:" ist ungültig, pro spec.

    Wäre es besser, wenn es "Info-Header" oder, genauer gesagt, nach der Spezifikation als "X-Info-Header" (so wie zu nicht im Widerspruch mit der Spezifikation vorbehalten-header-Namen)

    • Gut, es war ungültig in allen früheren Versionen von HTTP sowie.
    • Während seiner wahren, dass token nie erlaubt, die " " (Raum), die header-parsing-Regeln des früh-Spezifikationen im wesentlichen sagte, mit Blick auf das erste : (Doppelpunkt) und was vor dem Doppelpunkt ist der token, der im Widerspruch zu sich selbst. Glücklicherweise sind diese Arten von Widersprüchen korrigiert wurden (langsam) im Laufe der Jahre mit der aktualisierten specs.
    • Die "header-parsing-Regeln der frühen specs"? Zeiger, bitte.
    InformationsquelleAutor Joakim Erdfelt
Schreibe einen Kommentar