Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add cargo features for http1 and http2 #2251

Closed
2 tasks done
seanmonstar opened this issue Jul 28, 2020 · 5 comments
Closed
2 tasks done

Add cargo features for http1 and http2 #2251

seanmonstar opened this issue Jul 28, 2020 · 5 comments
Assignees
@seanmonstar
Labels
B-breaking-change Blocked: this is an "API breaking change". C-refactor Category: refactor. This would improve the clarity of internal code. E-medium Effort: medium. Some knowledge of how hyper internal works would be useful.
Milestone
0.14

Comments

@seanmonstar
Copy link
Member

seanmonstar commented Jul 28, 2020 •
edited
Loading

It's likely some people only need to support certain protocol versions, and it would be nice if they could reduce the amount of code they have to depend on or compile if they don't need all of them. It likely makes sense to add http1 and http2 Cargo features, and the relevant code using those cfgs.

  • http1
  • http2
@seanmonstar seanmonstar added E-medium Effort: medium. Some knowledge of how hyper internal works would be useful. B-breaking-change Blocked: this is an "API breaking change". C-refactor Category: refactor. This would improve the clarity of internal code. labels Jul 28, 2020
@seanmonstar seanmonstar added this to the 0.14 milestone Jul 28, 2020
@operutka
Copy link

This would be very useful. I'm working on a REST API for a small embedded device where the amount of flash memory is very limited. According to cargo bloat, the HTTP 2 protocol alone is responsible for a lot of code.

seanmonstar added a commit that referenced this issue Nov 10, 2020
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
914516e 
cc #2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
@seanmonstar seanmonstar mentioned this issue Nov 10, 2020
Merged
seanmonstar added a commit that referenced this issue Nov 10, 2020
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
cda0367 
cc #2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 10, 2020
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
146a1e2 
cc #2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 10, 2020
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
89427b1 
cc #2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 10, 2020
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
b819b42 
cc #2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
@seanmonstar seanmonstar self-assigned this Nov 12, 2020
@seanmonstar seanmonstar mentioned this issue Nov 12, 2020
Closed
@seanmonstar
Copy link
Member Author

As I wrap up adding http1, the question now arises: what should happen if you don't have any HTTP version enabled?

  • compile_error!: This could be the choice to start, since it's not a breaking change to eventually remove the compile error. However, if we have all features disabled by default, it could be jarring to see the build fail as soon as you add hyper and didn't configure any features...
  • An empty crate: it doesn't break, but it's otherwise not really useful...
  • A shell: Include the re-exports from http, body, and error. This could allow someone to build support crates using just the core types, without having to enable a specific protocol version.

@davidbarsky
Copy link
Contributor

As I wrap up adding http1, the question now arises: what should happen if you don't have any HTTP version enabled?

My gut feeling is that the "shell crate" option is the best option.

@KamilaBorowska
Copy link

KamilaBorowska commented Nov 16, 2020 •
edited
Loading

I think it would make sense to provide full crate but without functionality to actually construct clients or servers. However, methods like Client::request could stay (you cannot create an instance of Client anyway) for libraries that accept Client instances but don't need to create clients themselves.

seanmonstar added a commit that referenced this issue Nov 16, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
e2fcfc7 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
@seanmonstar seanmonstar mentioned this issue Nov 16, 2020
Merged
seanmonstar added a commit that referenced this issue Nov 16, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
4e2af5b 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 16, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
f58d995 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
9f5acc9 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
07fc512 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
7fa7bee 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
8a6b200 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
7f29357 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
seanmonstar added a commit that referenced this issue Nov 17, 2020
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
2a19ab7 
cc #2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
@seanmonstar
Copy link
Member Author

Both http1 and http2 features are merged! I'll file a separate issue about making them all default off.

@seanmonstar seanmonstar mentioned this issue Nov 17, 2020
Closed
BenxiangGe pushed a commit to BenxiangGe/hyper that referenced this issue Jul 26, 2021
@seanmonstar
feat(http2): Make HTTP/2 support an optional feature
303d1f8 
cc hyperium#2251

BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
  `http2` cargo feature, which will not be enabled by default. To use
  HTTP/2, add `features = ["http2"]` to the hyper dependency in your
  `Cargo.toml`.
BenxiangGe pushed a commit to BenxiangGe/hyper that referenced this issue Jul 26, 2021
@seanmonstar
feat(http1): Make HTTP/1 support an optional feature
c306029 
cc hyperium#2251

BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
  `http1` cargo feature, which will not be enabled by default. To use
  HTTP/1, add `features = ["http1"]` to the hyper dependency in your
  `Cargo.toml`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@seanmonstar seanmonstar

Labels
B-breaking-change Blocked: this is an "API breaking change". C-refactor Category: refactor. This would improve the clarity of internal code. E-medium Effort: medium. Some knowledge of how hyper internal works would be useful.
Projects
None yet
Milestone
0.14
Development

No branches or pull requests
4 participants
@seanmonstar @KamilaBorowska @operutka @davidbarsky