hyperium / hyperium/http

Fix URI, Request target terminology.

Open
#523 2 comments 8 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.4k
Forks
378
Avg merge
1d 21h
Merged PRs (30d)
5

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the crate's current Uri struct and request-target handling documentation, then review the related issues listed in the report. Done means the terminology consistently describes request-target forms and the public naming change has an explicit compatibility decision before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.