-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
quiche: handle multiple cookies and multiple set-cookie headers #14969
Conversation
Signed-off-by: Dan Zhang <[email protected]>
/retest |
Retrying Azure Pipelines: |
/assign @alyssawilk |
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.
Thanks for the continued effort to add QUIC support to Envoy.
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.
Thanks for catching this one - cookie headers are easy to screw up!
I think adding multiple entries is a fine behavior for the cookie header.
Is there a reason you want to inline?
My thought is we could fix appendToHeader to instead of having the default
of ",", have a helper function which checked for cookie/set-cookie. Either
that or we could fix appendCopy to make sure it did the checks, which would
arguably be cheaper, and then ASSERT in appendToHeader that if it's
cookie/set-cookie the correct delimiter applies.
…On Tue, Feb 9, 2021 at 12:50 PM danzh ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In include/envoy/http/header_map.h
<#14969 (comment)>:
> @@ -294,7 +294,8 @@ class HeaderEntry {
HEADER_FUNC(Protocol) \
HEADER_FUNC(Scheme) \
HEADER_FUNC(TE) \
- HEADER_FUNC(UserAgent)
+ HEADER_FUNC(UserAgent) \
+ HEADER_FUNC(Cookie)
There seems to be no set-cookie related changes in this PR. Is the
set-cookie behavior already correct and just requires extra testing?
set-cookie is already handled in Envoy HeaderMapImpl and is unit-tested
and also tested in protocol integration tests.
------------------------------
In include/envoy/http/header_map.h
<#14969 (comment)>:
> @@ -294,7 +294,8 @@ class HeaderEntry {
HEADER_FUNC(Protocol) \
HEADER_FUNC(Scheme) \
HEADER_FUNC(TE) \
- HEADER_FUNC(UserAgent)
+ HEADER_FUNC(UserAgent) \
+ HEADER_FUNC(Cookie)
I think this will result in Envoy inlining cookie headers, which is a
pretty large change we should avoid if we can.
According to the interface contract, HeaderMapImpl::insertByKey() only
concatenate predefined inline headers. For other headers it will add
multiple entries. If we don't prefer to inline cookie headers, the
delimiter I added in insertByKey() won't work for cookie header. Maybe I
should do what H2 does? Http2 codec coalesces cookie values into a class
member variable via reconstituteCrumbledCookie() upon receiving each header
and adds a "cookie" header at the end. Or change the contract to use
concatenate for non-inlined headers as well. Which one is better?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#14969 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AELALPIBBKWVXNZAPFLPTRTS6FYXHANCNFSM4XF5DU7A>
.
|
Multiple cookie headers are allowed according to the RFC, but H2 codec seems reconstitute them into a single header with semi-colon separated values. QUICHE is a bit different here. It splits all the cookie headers even if the client sends them in a single header. I want to coalesce them just because H2 does that. |
I don't mind us coalescing HTTP/3 if that keeps HTTP/2 and HTTP/3 closer, but my concern is I believe you're also changing HTTP/1, with no runtime guards or recourse which I don't think is a viable change (unless I'm wrong and something in http parser also coalesces cookie headers - you're welcome to test my assumptions here!) |
Signed-off-by: Dan Zhang <[email protected]>
Signed-off-by: Dan Zhang <[email protected]>
I added runtime guard to change in HeaderMapImpl. And also moved the change from insertByKey() to appendCopy(). PTAL! |
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.
This looks much safer, thanks for the iteration!
It looks like the other 2 call sites for appendToHeader only apply to inline headers but I wouldn't mind a double check from @snowp
I also wonder if it's worth just making that argument non-optional and from those 2 call sites calling it for kDelimiterForInlineHeaders with a comment on definition that all inline headers use comma delimiter. Possibly overkill so I'll say that's 100% optional :-P
@@ -89,6 +89,7 @@ constexpr const char* runtime_features[] = { | |||
"envoy.reloadable_features.unify_grpc_handling", | |||
"envoy.reloadable_features.upstream_http2_flood_checks", | |||
"envoy.restart_features.use_apple_api_for_dns_lookups", | |||
"envoy.reloadable_features.header_map_coalesce_cookie_headers", |
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 don't think this will result in cookies coalescing, but in correctly coalescing cookies. WDYT?
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.
renamed it!
// TODO(danzh): Avoid copy by referencing entry as header_list is already validated by QUIC. | ||
headers->addCopy(Http::LowerCaseString(entry.first), entry.second); | ||
auto key = Http::LowerCaseString(entry.first); | ||
if (!Runtime::runtimeFeatureEnabled( |
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.
FWIW I don't think you need to runtime guard QUIC code if youdon't want to as it's still alpha
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.
good point! Removed the runtime guard here but still checks it in tests.
/retest |
Retrying Azure Pipelines: |
It's hard to tell if the following interface are used anywhere with a delimiter different from comma:
|
Signed-off-by: Dan Zhang <[email protected]>
/retest |
Retrying Azure Pipelines: |
Ping? |
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.
code LGTM.
Let's add release notes in docs/root/version_history/current.rst
(bug fix, include the runtime guard)
and a header map impl test, and I think you're good to go.
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.
It looks like the other 2 call sites for appendToHeader only apply to inline headers but I wouldn't mind a double check from @snowp
This seems right to me, can't find any use cases besides the ones applying to inlined headers.
Signed-off-by: Dan Zhang <[email protected]>
Updated current.rst. There is a new header map unit test for the new feature. What else need to be tested? |
Signed-off-by: Dan Zhang <[email protected]>
Signed-off-by: Dan Zhang <[email protected]>
Signed-off-by: Dan Zhang <[email protected]>
/retest |
Retrying Azure Pipelines: |
/retest |
Retrying Azure Pipelines: |
/retest |
Retrying Azure Pipelines: |
Argh - CI passed but there's conflicts. Needs a main merge :-/ |
Signed-off-by: Dan Zhang <[email protected]>
Signed-off-by: Dan Zhang <[email protected]>
Signed-off-by: Dan Zhang <[email protected]>
Done with main merge. PTAL |
/retest |
Retrying Azure Pipelines: |
sync'ed with upstream. PTAL! |
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.
Thanks, this LGTM.
Seems like this PR no longer contains any changes to how we handle set-cookie? Do we no longer need to make any changes to properly support that in with QUIC?
set-cookie was handled correctly before. This change add tests for it. |
Any other thoughts on this change? @alyssawilk |
Commit Message: ensure that the inline cookie header will be folded correctly Additional Description: This PR is a supplement to #17330 and #14969 and will finally close #17234. This PR mainly did following works: update insertByKey to choose suitable delimiter for inline header. update parseCookie to avoid unnecessary iteration for parsing cookie value. Risk Level: Low. Testing: Add. Docs Changes: N/A. Release Notes: N/A. Signed-off-by: wbpcode <[email protected]>
…roxy#17560) Commit Message: ensure that the inline cookie header will be folded correctly Additional Description: This PR is a supplement to envoyproxy#17330 and envoyproxy#14969 and will finally close envoyproxy#17234. This PR mainly did following works: update insertByKey to choose suitable delimiter for inline header. update parseCookie to avoid unnecessary iteration for parsing cookie value. Risk Level: Low. Testing: Add. Docs Changes: N/A. Release Notes: N/A. Signed-off-by: wbpcode <[email protected]>
Signed-off-by: Dan Zhang [email protected]
Commit Message: fix some issues around duplicated http headers:
Quiche doesn't coalesce duplicated headers, so we need to coalesce them in Envoy. Cookie headers after coalescing are semi-colon separated, while Set-Cookie headers shouldn't be coalesced.
Risk Level: low
Testing: added unit tests and integration tests.
Part of #2557