Skip to content

http: fixing CONNECT to not advertise chunk encoding.#11245

Merged
alyssawilk merged 3 commits intoenvoyproxy:masterfrom
alyssawilk:no_chunk
May 19, 2020
Merged

http: fixing CONNECT to not advertise chunk encoding.#11245
alyssawilk merged 3 commits intoenvoyproxy:masterfrom
alyssawilk:no_chunk

Conversation

@alyssawilk
Copy link
Copy Markdown
Contributor

Risk Level: low (connect only)
Testing: UT, IT
Docs Changes: n/a
Release Notes: n/a
Fixes #11227
Part of #1451

Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with small comments. Thanks for the quick fix!

/wait

bool HeaderUtility::isConnectResponse(const RequestHeaderMapPtr& request_headers,
const ResponseHeaderMap& response_headers) {
return request_headers.get() && isConnect(*request_headers) &&
Http::Utility::getResponseStatus(response_headers) == 200;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: s/200/Http::Code::OK

} else {
encodeFormattedHeader(Headers::get().TransferEncoding.get(),
Headers::get().TransferEncodingValues.Chunked);
// For responses to connct requests, do not send the chunked encoding header:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo connct, same below

Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
tcp_client->waitForData("\r\n\r\nreturn-payload", false);

tcp_client->close();
// The response will be rejected because chunked headers are not allowed with CONNECT upgrades.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me see if I understand this correctly: does this means that Envoy will reject a proxied HTTP CONNECT if the upstream proxy server happens to send a TE header in the response?

This seems like it might break some upstream proxies that aren't carefully implemented. Is there a reason to reject these responses rather than just ignoring the header?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately Envoy will strip the TE header (that's pretty strongly asserted across the code base) and not add it back. AFIK if there is a TE header there ought to be TE-chunked data, and so by altering that header we'd be sending potentially compromised payload.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just so I'm clear: do you mean Envoy strips TE whenever it appears or just for the CONNECT case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Envoy always strips TE for headers passing through Envoy.
It re-emits TE for HTTP/1.1 requests/responses which may have bodies if there's no content length provided. Given for connect it is not allowed to have T-E it wouldn't know to reapply it, so it'd end up in an inconsistent state I'd like to avoid.
Worst case if there's a widely deployed proxy which does this illegal thing we could transform T-E into some Had-TE-Header and reinstate it, but I'd rather err on the side of simplicity until-if someone complains.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems fair. Thanks for educating me :)

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending the concern from @chradcliffe. Thank you!

@alyssawilk alyssawilk merged commit 3c6a95e into envoyproxy:master May 19, 2020
spenceral added a commit to spenceral/envoy that referenced this pull request May 20, 2020
Signed-off-by: Spencer Lewis <slewis@squareup.com>

* master: (33 commits)
  docs: break release notes into categories (envoyproxy#11217)
  admin: extract more handlers to separate classes  (envoyproxy#11258)
  Load reporting service documentation  (envoyproxy#10962)
  http: testing 304-with-body behavior (envoyproxy#11261)
  fixing typos and breaking link issues (envoyproxy#11270)
  devex: initial commit of devcontainer setup (envoyproxy#11207)
  security: update policy for fix/disclosure SLOs. (envoyproxy#11243)
  http: fixing CONNECT to not advertise chunk encoding. (envoyproxy#11245)
  docs: update upstream network filters description (envoyproxy#11231)
  deps: update datadog tracer to v1.1.5 (envoyproxy#11253)
  test: Fix missing instantiation of parameterized tests. (envoyproxy#11247)
  fix go mirror when no changes (envoyproxy#11249)
  docs: host_rewrite -> host_rewrite_literal (envoyproxy#11229)
  wasm: update V8 to v8.3.110.9. (envoyproxy#11233)
  tls: update BoringSSL to 107c03cf (4103). (envoyproxy#11232)
  bazelci: always exclude nocoverage tag in coverage config (envoyproxy#11226)
  ci: save api revision in go-control-plane (envoyproxy#11220)
  build: fix cares build (envoyproxy#11225)
  stats: Pre-allocate codec stats for http1 and http2 (envoyproxy#11135)
  api: manifest based edge default documentation. (envoyproxy#11151)
  ...
@alyssawilk alyssawilk deleted the no_chunk branch August 27, 2020 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Terminating HTTP CONNECT 200 response should not send "Transfer-Encoding: chunked" header

3 participants