Comments (8)
One alternative could be perhaps taking &Bytes
instead of Bytes
. That way an API which doesn't clone the input bytes (e.g. Version
) wouldn't clone anything whereas other APIs (like HeaderName
and such) would clone.
from http.
Relates to #23
from http.
I would personally recommend "no" here. I think for generics it might matter but it looks like nothing is generic in this crate:
$ rg -- '-> Result'
src/status.rs: pub fn from_u16(src: u16) -> Result<StatusCode, FromU16Error> {
src/status.rs: pub fn from_bytes(src: &[u8]) -> Result<StatusCode, FromStrError> {
src/status.rs: fn from_str(s: &str) -> Result<StatusCode, FromStrError> {
src/uri.rs:fn parse(s: &[u8]) -> Result<Marks, ErrorKind> {
src/uri.rs:fn parse_scheme(s: &[u8]) -> Result<(Scheme, usize, &[u8]), ErrorKind> {
src/uri.rs:fn parse_authority(s: &[u8], pos: usize) -> Result<u16, ErrorKind> {
src/uri.rs:fn parse_full(s: &[u8]) -> Result<Marks, ErrorKind> {
src/uri.rs:fn parse_query(s: &[u8], pos: usize) -> Result<(u16, u16), ErrorKind> {
src/uri.rs: fn from_str(s: &str) -> Result<Uri, FromStrError> {
src/method.rs: pub fn from_bytes(src: &[u8]) -> Result<Method, FromBytesError> {
src/method.rs: fn extension_inline(src: &[u8]) -> Result<Method, FromBytesError> {
src/method.rs:fn write_checked(src: &[u8], dst: &mut [u8]) -> Result<(), FromBytesError> {
src/header/value.rs: pub fn try_from_str(src: &str) -> Result<HeaderValue, InvalidValueError> {
src/header/value.rs: pub fn try_from_bytes(src: &[u8]) -> Result<HeaderValue, InvalidValueError> {
src/header/value.rs: pub fn to_str(&self) -> Result<&str, ToStrError> {
src/header/name.rs: -> Result<HdrName<'a>, FromBytesError>
src/header/name.rs: pub fn from_bytes(src: &[u8]) -> Result<HeaderName, FromBytesError> {
src/header/name.rs: fn from_str(s: &str) -> Result<HeaderName, FromStrError> {
src/header/name.rs: pub fn from_bytes<F, U>(hdr: &[u8], f: F) -> Result<U, FromBytesError>
The only generic there, HdrName::from_bytes
, isn't exposed publicly. Otherwise everything else is just parsing strings/bytes it looks like. In the standard library for Utf8Error
returned by str::from_utf8
only contains indexes.
What we could capture is the lifetime of the input into the output (e.g. add lifetime parameters to error types) but I think tha'd be less ergonomic to work with
So basically:
- I don't think there's any generics to capture today (unless I missed one?)
- I don't think we should capture lifetimes
- If we really want to convey indexing/extra information, we can do so with indices backwards-compatibly
In that sense I'd be ok with closing this issue with no further action. Thoughts?
from http.
cc #58, some more thoughts on errors
from http.
@alexcrichton the main "issue" is if you pass in a Bytes
by value, you will lose the handle if there is an error. It's not super critical because cloning is shallow, so you can always clone before you try to convert if you really want to hold on to the input on error.
I don't care strongly either way right now, so I'm fine w/ not returning the input.
from http.
Conclusion from discussion yesterday: We should add "owned" variants of errors where the input is Bytes
, but otherwise punt for now. We won't add functions to retrieve the Bytes
yet, we just want to have the opportunity to add these functions later.
from http.
But before releasing 0.1, any conversion from Bytes
has to have a separate type (though, w/o necessarily exposing the inner Bytes
yet). Otherwise, it would be backwards compat breaking?
Edit: that's what #65 does.
from http.
Oh certainly! That's #65
from http.
Related Issues (20)
- Clear contents of sensitive header values on drop HOT 2
- Why does canonical_reason() return a Option? HOT 3
- Rename 422 from "Unprocessable Entity" to "Unprocessable Content"
- const fn for `StatusCode::as_u16` HOT 1
- can't parse uri without scheme but having path HOT 4
- 1.0 vs 0.2 incompatibility HOT 1
- Allow customizing header casing
- Add a `Display` impl for `Request` and `Response` to reconstruct the raw HTTP message HOT 2
- impl std::error::Error for StatusCode HOT 1
- http::method::Method::FromStr implementation allows invalid methods, conflicting with from_str documentation HOT 2
- Invalid uri parse HOT 1
- `http::uri::Uri` is excessively large and makes unnecessary allocations HOT 2
- Failed to parse a valid url HOT 1
- Uri does not parse valid URIs with empty authority portion HOT 1
- Add 420 Enhance Your Calm status code
- How to append a queryparams string after using uri_mut().into_parts()? HOT 1
- `index out of bounds` when parsing a valid header value HOT 2
- Request headers containing Russian (and possibly other non-English) characters fail with `UTF-8 encoding error` HOT 1
- HeaderMap::try_with_capacity can panic when capacity is large
- RFC: Add `parts_mut() -> &mut Parts` to allow mutate parts directly HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from http.