-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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.
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
Backport 0.14.x: feat(http1): support configurable max_headers #3773
base: 0.14.x
Are you sure you want to change the base?
Conversation
@@ -169,14 +170,17 @@ impl Http1Transaction for Server { | |||
// but we *never* read any of it until after httparse has assigned | |||
// values into it. By not zeroing out the stack memory, this saves | |||
// a good ~5% on pipeline benchmarks. | |||
let mut headers_indices: [MaybeUninit<HeaderIndices>; MAX_HEADERS] = unsafe { | |||
// SAFETY: We can go safely from MaybeUninit array to array of MaybeUninit | |||
MaybeUninit::uninit().assume_init() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I should preserve unsafe
and call assume_init
// Unsafe: see comment in Server Http1Transaction, above. | ||
let mut headers_indices: [MaybeUninit<HeaderIndices>; MAX_HEADERS] = unsafe { | ||
// SAFETY: We can go safely from MaybeUninit array to array of MaybeUninit | ||
MaybeUninit::uninit().assume_init() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I should preserve unsafe
and call assume_init
client = [] | ||
server = [] | ||
client = ["dep:smallvec"] | ||
server = ["dep:smallvec"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just ported it from #3523.
I'm not sure if it's required or not.
2c08250
to
c42aec7
Compare
As a general question / expectation-setting question about backports onto the 0.x line, is this PR following the repository's expectations around submitting backports? Are there other things you'd like to see done before considering this contribution? Additionally, is there a regular schedule for when backport releases would take place after PRs are reviewed and merged? Thanks! |
Backport #3523 to
0.14.x
.Context: At my work, we can't update to
1.x
, but we need this change to fix the customer's issue.I backported #3523 and tried to resolve all conflicts.
Tests are passing, but I'm not sure about a few places.
I will mark this place with comments.