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 no_std support #551

Open
Stupremee opened this issue May 10, 2022 · 6 comments · May be fixed by #740
Open

Add no_std support #551

Stupremee opened this issue May 10, 2022 · 6 comments · May be fixed by #740
Labels
E-medium Effort: medium. S-feature Severity: feature. This adds something new.

Comments

@Stupremee
Copy link

Hello,

I'm currently in need of a correct Uri parser, and I believe the best URI implementation is the one in this crate.
However, I don't want to add the whole http crate as a dependency.
So, it would be very helpful if there was an additional crate just for URI parsing.
@LucioFranco
Copy link
Member

Is there a reason you don't want to just bring in the whole http crate? The dependency is already quite light. I don't think moving things to their own crate makes anyone's life easier.

@Stupremee
Copy link
Author

The reason is that http does not have support for no_std environments.

@LucioFranco
Copy link
Member

Maybe a better goal would be to allow http to support no_std similar to how bytes has no_std support. I don't think the correct solution is to create another crate.

@Stupremee
Copy link
Author

Sure, that would work as well!

@LucioFranco LucioFranco changed the title Move uri module into extra crate Add no_std support Jun 23, 2022
@LucioFranco LucioFranco added S-feature Severity: feature. This adds something new. E-medium Effort: medium. labels Jun 23, 2022
@Erik1000
Copy link

Erik1000 commented Jul 9, 2022

+1 for this

@Erik1000 Erik1000 mentioned this issue Aug 8, 2022
Closed
@olanod
Copy link

olanod commented Aug 11, 2022

My use case is an HTTP client running in embedded hardware, hope this PR(#563) can get some feedback :) Ideally it would be nice if http works without alloc but that seemed like a mayor refactor and possibly breaking change.

@robjtede robjtede mentioned this issue Aug 11, 2022
Closed
@Farhad-Shabani Farhad-Shabani mentioned this issue Jan 2, 2024
Merged
7 tasks
@brandonros brandonros mentioned this issue Dec 1, 2024
Draft
sunfishcode added a commit to sunfishcode/http that referenced this issue Jan 2, 2025
@sunfishcode
no_std support.
b1e6a7a 
This PR is similar to other no-std PRs, however it takes the approach of
using the new [`core::error`] module in Rust 1.81. This means that no-std
mode has an MSRV of Rust 1.81, while the existing MSRV of 1.49 is still
supported for existing users, as suggested [here].

This PR also preserves semver compatibility, and avoids adding any new
dependencies or required features for existing users. And it avoids
modifying the tests and benchmark sources, as those don't need to be no-std.
And it avoids making any unrelated changes.

And, it adds CI coverage and README.md documentation.

[here]: hyperium#563 (comment)
[`core::error`]: https://doc.rust-lang.org/stable/core/error/index.html

Fixes hyperium#551.
@sunfishcode sunfishcode linked a pull request Jan 2, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
E-medium Effort: medium. S-feature Severity: feature. This adds something new.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

no_std support. sunfishcode/http
4 participants
@olanod @LucioFranco @Stupremee @Erik1000