-
Notifications
You must be signed in to change notification settings - Fork 5.3k
router: add support for direct (non-proxied) http responses. #2335
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
Changes from all commits
942d251
eec6775
3f04d58
dfc0b8d
ea91a05
77a170f
49b2732
e309720
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -195,7 +195,7 @@ Http::FilterHeadersStatus Filter::decodeHeaders(Http::HeaderMap& headers, bool e | |
| // that get handled by earlier filters. | ||
| config_.stats_.rq_total_.inc(); | ||
|
|
||
| // Determine if there is a route entry or a redirect for the request. | ||
| // Determine if there is a route entry or a direct response for the request. | ||
| route_ = callbacks_->route(); | ||
| if (!route_) { | ||
| config_.stats_.no_route_.inc(); | ||
|
|
@@ -209,11 +209,18 @@ Http::FilterHeadersStatus Filter::decodeHeaders(Http::HeaderMap& headers, bool e | |
| return Http::FilterHeadersStatus::StopIteration; | ||
| } | ||
|
|
||
| // Determine if there is a redirect for the request. | ||
| if (route_->redirectEntry()) { | ||
| config_.stats_.rq_redirect_.inc(); | ||
| Http::Utility::sendRedirect(*callbacks_, route_->redirectEntry()->newPath(headers), | ||
| route_->redirectEntry()->redirectResponseCode()); | ||
| // Determine if there is a direct response for the request. | ||
| if (route_->directResponseEntry()) { | ||
| auto response_code = route_->directResponseEntry()->responseCode(); | ||
| if (response_code >= Http::Code::MultipleChoices && response_code < Http::Code::BadRequest) { | ||
| config_.stats_.rq_redirect_.inc(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we probably want a direct response stat which supplements (and hopefully eventually replaces) the redirect stat.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added a counter of direct responses. Is there a precedent in Envoy for also having counters per response status or per response code family (2xx, 3xx, etc)?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We already have split out codes for all downstream responses. IMO that's probably sufficient. |
||
| Http::Utility::sendRedirect(*callbacks_, route_->directResponseEntry()->newPath(headers), | ||
| response_code); | ||
| return Http::FilterHeadersStatus::StopIteration; | ||
| } | ||
| config_.stats_.rq_direct_response_.inc(); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. please add an expectation in one of the tests that checks this stat gets incremented.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, and I almost forgot - we should update docs for this. Please add an envoy-API pull updating router_filter.rst and note it in your PR description
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @brian-pane you plan on finishing up docs in a follow up, right?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I was planning to make a followup PR that adds the remainder of this feature (adding optional response headers and body), with the docs linked to that new PR.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK that works. Will merge this. |
||
| sendLocalReply(route_->directResponseEntry()->responseCode(), "", false); | ||
| // TODO(brian-pane) support sending a response body and response_headers_to_add. | ||
| return Http::FilterHeadersStatus::StopIteration; | ||
| } | ||
|
|
||
|
|
||
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'd prefer this replace RedirectEntry rather than be a slightly duplicate thing.
newPath could be optional, and expected for redirect responses. I'm neutral if it should be done here or in a follow-up but maybe add a TODO?
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 suggestion; combining RedirectEntry and DirectResponseEntry sounds good to me. The combined code will have to deal with some incompatibilities between the two -- e.g., under the current data plane API, redirects aren't allowed to send the
response_headers_to_add, whereas direct responses are required to -- but it will probably still be cleaner than the current diff.I'll merge the implementations post an update to this PR later today.
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.
cool. hopefully if we do some sanity checks with an IsRedirectReturnCode() in the right places we'll guard against bad configs/code
Uh oh!
There was an error while loading. Please reload this page.
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 see any reason redirects cannot also populate response_headers_to_add. That seems pretty useful to me. Thoughts?
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.
Adding response_headers_to_add to redirects would change the behavior of existing configs. If we were designing the config schema from scratch, I’d advocate for sending the headers with redirects. But at this point it would impact backward compatibility. Unless we added a “send_headers_with_redirects” flag that defaults to false, I suppose :(
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.
Yeah, fair enough. I kind of think we could "just do it" and document it in this case as a change. But that's me. Fine to block/TODO for now if you think that would be best.