Header fields should be case insensitive (RFC 7230 §3.2, RFC 9110 §5.1)
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- rust
- Bereich
- api, networking
Rechercherichtung
Beginne damit, das Verhalten von HeaderMap::get und HeaderMap::insert gemeinsam mit HeaderName::from_static zu untersuchen, wobei die Groß-/Kleinschreibungs-sensitiven Beispiele im Issue als Reproduktion dienen. Erledigt ist die Aufgabe, wenn der Abruf von Header-Namen unterschiedliche Groß-/Kleinschreibung akzeptiert, from_static bei gültigen Feldnamen nicht mehr panikt und die ursprüngliche Groß-/Kleinschreibung erhalten bleibt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
I'm working with http::HeaderMap and noticed that HeaderMap::get, HeaderMap::insert, and HeaderName::from_static all seem to be case sensitive (in fact, the latter panics:
HeaderName::from_static("Content-Type")
panics with:
index out of bounds: the len is 0 but the index is 0
while:
HeaderName::from_static("content-type")
does not.
This goes against the HTTP spec requiring case-insensitive handling of header values:
- RFC 7230 §3.2
Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace.
- RFC 9110 §5.1
Field names are case-insensitive...
IMO, this is distinct from #670, and in fact case-insensitive keys should solve that issue as well, while not requiring the original cases to be changed.
It looks like crates like case_insensitive_hashmap and unicase are examples of case-insensitive String handling.
Is there any way to just make the HeaderMap case-insensitive for retrieval? That would preserve original case as well as allow any case for HeaderMap::get to meet the spec and prevent errors.
- Vorherrschende Sprache
- Rust
- Sterne
- 1.4k
- Forks
- 385
- Ø Merge
- 1 T. 5 Std.
- Gemergte PRs (30 T.)
- 2
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus hyperium/http
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 52/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 62/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
Maintainer antworten meist innerhalb von 3 Tagen
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Zellij doesn't validate hex colors correctly and crashesEvtl. vergeben @ymcx hat das heute übernommen. Offensuspected bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
zellij-org/zellij#5732 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug(api): E_DOSE_ATTR_NONFINITE for a modeled D/R still says the value "never reaches you as a NaN"Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 63/100