Compiling with `cargo 1.63.0-nightly (3f052d8ee 2022-05-12)` I get lots
of errors like this:
```
error: `#[doc(hidden)]` is ignored on trait impl items
--> src/header/map.rs:3296:9
|
3296 | #[doc(hidden)]
| ^^^^^^^^^^^^^^ help: remove this attribute
|
note: the lint level is defined here
--> src/lib.rs:161:9
|
161 | #![deny(warnings, missing_docs, missing_debug_implementations)]
| ^^^^^^^^
= note: `#[deny(unused_attributes)]` implied by `#[deny(warnings)]`
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: whether the impl item is `doc(hidden)` or not entirely depends on the corresponding trait item
```
This commit removes all these unnecessary attributes so that `http` compiles
again with Nightly.
* From impls of PathAndQuery and Authority for Uri
A Uri may logically hold only an Authority or only a PathAndQuery.
Should an application want to make such Uris, it would be easier to
safely create them by first making just an Authority or just a
PathAndQuery, then cheaply convert them directly into a Uri.
* Fix Uri docs
The doc comments for `impl From<Uri> for Parts` actually described
`Uri::from_parts`.
... plus some clean-up.
It was only after I came up with the scheme using
`const fn from_bytes(&[u8]) -> Option<StandardHeader>`
that I noticed the debug+wasm32-wasi version of `parse_hdr`, which had
something very similar.
While cleaning up that function, I realized it still would still panic
if an attempted name was too long, which had been fixed for all other
targets and profiles in #433. Then, I thought it would be worth seeing
if the use of `eq!` in the primary version of `parse_hdr` still made any
difference.
And, it would not appear so. At least not on x86_64, nor wasm32-wasi run
via wasmtime. I've run the benchmarks a number of times now, and it
seems the only significant performance change anywhere is actually that
of `HeaderName::from_static` itself, which now seems to run in about 2/3
the time on average.
Unfortunately, `const fn` still cannot `panic!`, but I've followed the
lead from `HeaderValue::from_static`. While that version required 1.46,
this new function requires 1.49. That is almost 8 months old, so
hopefully this isn't too controversial!
This crate declares `edition = 2018`, in which these `extern crate` instructions are no longer necessary, so it should be safe to remove them from the README file.
`HeaderValue` implements `TryFrom` over both reference and owned types, but `HeaderName` does not. This seemed like an accidental omission to me rather than something intentionally absent. Including this conversion slightly increases ergonomics by allowing you to create a `HeaderMap` from a `HashMap<String, String>` and in similar other constraints.
See also https://github.com/sagebind/isahc/issues/314.
* add test case for OccupiedEntry::remove_entry_mult
This is just a self contained test case, currently reproducing the
panic of #446.
* expand test cases for remove_entry_mult
* add multiple remove_entry_mult call tests to show more issues
* test repeated HeaderMap::remove for comparison
* tests showing similar problem with remove_entry on extra values
* fix remove_entry by moving remove_found after remove_all_extra_values
* fix remove_entry_mult by eager collection of extras before remove_found
In order to remove extra values prior to remove_found, we must collect
them eagerly. Eager collection is based on:
commit 8ffe094df1
Author: Sean McArthur <sean@seanmonstar.com>
AuthorDate: Mon Nov 25 17:34:30 2019 -0800
Commit: Sean McArthur <sean@seanmonstar.com>
CommitDate: Tue Nov 26 10:03:09 2019 -0800
Make ValueDrain eagerly collect its extra values
...which was reverted in 6c2b7897ef.
Closes#446
When building a URI, it is not possible to provide neither String nor
&String, which is useful when adding a path_and_query from a string
built using format!.
This commit adds implementation of From<String> and From<&String> for
PathAndQuery.
Additionally, reduces the size of the static memory included, and reduces some of the complicated macro usage resulting in faster compiles!
Co-authored-by: quininer <quininer@live.com>
Co-authored-by: David Kellum <dek-oss@gravitext.com>
Fixes#432.
This eliminates an undocumented panic from the `HeaderName` creation functions, returning instead an
`InvalidHeaderName` when the name length exceeds `MAX_HEADER_NAME_LEN`.
I considered making `InvalidHeaderName` a richer error type, but since it was already used for
another type of length error (rejecting zero-length names) I figured it was okay to reuse.
I also redefined `MAX_HEADER_NAME_LEN` slightly, so that it is equal to the largest allowed header
length, rather than one past that value. This was motivated by discovering a bug in my comparison
logic when I went to write the new test exercising the wrong-length error conditions.
While the documentation mentions that header values can be marked as
sensitive in order to inform outside components that these header values
may require special treatment, it was unclear to me whether doing that
affects the behavior of this crate.
This adds a short note to the documentation to clarify that the main
purpose of the sensitivity flag is to make components building on this
crate to be aware of sensitive data, such that it can be treated with
special care for security purposes.
This change makes the alt tag for the badge image closer to what is
shown in the immage itself (both are will show the name of the workflow:
CI) and makes the badge a link to the summary page for the CI workflow
in the GitHub Actions web interface.
* Add unit test for rejecting invalid UTF-8
* Add Authority::from_static() test
* Refactor uri::Authority
Extract the common code from three ways of creating an Authority into a
private create_authority() function.
* Add comments to explain the safety of Authority
The comments describe the preconditions and postconditions that together
ensure that the one use of 'unsafe' in uri/authority.rs is sound.
* Fix typo
The internal InlineExtension and AllocatedExtension types have
invariants that ensure that the two uses of "unsafe" in the "extension"
submodule of "method" are safe. This documents those invariants for
future reference.
Extract the inner types for ExtensionAllocated and ExtensionInline into
a separate extension module that has the supporting functions as
non-public elements.
This refactoring moves the use of "unsafe" into this new "extension"
module and provides a safe wrappers around the two uses of "unsafe".
openharmony_ci