Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Fix URI, Request target terminology.

Aperta
#523 2 commenti 8 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust

Direzione di ricerca

Inizia dalla documentazione relativa all'attuale struttura Uri del crate e alla gestione di request-target, quindi esamina le issue correlate elencate nel report. Il lavoro è completato quando la terminologia descrive in modo coerente le forme di request-target e il cambiamento del nome pubblico ha una decisione esplicita sulla compatibilità prima dell'implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

As this crate stands for correctness, it is imperative to fix misleading terminology that is used through out the request-target handling documentation.

  1. Use HttpRequestTarget instead of Uri, as it really handles only request target forms, not identity scheme in any way. This may be difficult, noting it is a breaking change. Can alias and deprecate though.
  2. In documentation of current Uri struct, There is extensive use of absolute-uri/relative-uri dichotomy to show that, for absolute-uri it has port, scheme, etc, and for relative-uri it won't. This is grossly misleading. As this crate is not handling identifiers in the first place, there is no such thing as absolute-uri/relative-uri dichotomy. It is instead dichotomy of absolute-form/origin-form of request target. i.e, request-target in absolute-form encodes port, scheme etc, and that in origin-form doesn't, as they have to be runtime-resolved. That's also the reason the mis-termed relative-uris starts with a /, as they are not really identifiers, relative/absolute, but origin-form resource targets.

The second point of fixing documentation may not be breaking change, and possible i hope.

We can see many misunderstandings due to this misleading. for example

  1. #127, As These are not identifiers, but representation of request-target values, there is no uri, and thus no fragments in first place.
  2. #465 Same mis-issue of using request-target representation to represent identifiers
  3. #469 They even mention other uri-schemes in issue discription, and also quotes uri-standard. Same mis-issue.
  4. #396 , url crate is for identifiers, where as this one only deals with request-targets.
  5. #379 same issue. This crate doesn't handles uris in first place. only request targets.
  6. #342
  7. #311
  8. #323
  9. #421
  10. #306
  11. #176
  12. #110

so on, so forth.
For amount of confusion, ad misleading it creates, It may be helpful to fix at least terminology in docs, and fix Uri name for struct before 1.0

see https://github.com/solid/specification/issues/368

Lingua principale
Rust
Stelle
1.4k
Fork
378
Merge medio
1g 21h
PR unite (30g)
5

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyperium/http

Tutte le issue di hyperium/http

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.