-
Notifications
You must be signed in to change notification settings - Fork 5.5k
http: rc details for main Envoy workflow #6560
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
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
78e41f2
WIP: rc details for main Envoy workflow
alyssawilk f576258
format
alyssawilk 84414ff
Merge branch 'master' into sendLocalReply
alyssawilk eee0b1b
cleanup, reviewer comments, tests
alyssawilk effdd68
always using consts
alyssawilk 204db09
reviewer comments
alyssawilk 5b50401
one last comment
alyssawilk 47b7db6
comments
alyssawilk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -76,8 +76,57 @@ enum ResponseFlag { | |
| struct ResponseCodeDetailValues { | ||
| // Response code was set by the upstream. | ||
| const std::string ViaUpstream = "via_upstream"; | ||
|
|
||
| // TODO(#6542): add values for sendLocalReply use-cases | ||
| // Envoy is doing non-streaming proxying, and the request payload exceeded | ||
| // configured limits. | ||
|
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. Looks like this comment is cut off. |
||
| const std::string RequestPayloadTooLarge = "request_payload_too_large"; | ||
| // Envoy is doing non-streaming proxying, and the response payload exceeded | ||
| // configured limits. | ||
| const std::string ResponsePayloadTooLArge = "response_payload_too_large"; | ||
| // The per-stream keepalive timeout was exceeded. | ||
| const std::string StreamIdleTimeout = "stream_idle_timeout"; | ||
| // The per-stream total request timeout was exceeded | ||
| const std::string RequestOverallTimeout = "request_overall_timeout"; | ||
| // The request was rejected due to the Overload Manager reaching configured resource limits. | ||
| const std::string Overload = "overload"; | ||
| // The HTTP/1.0 or HTTP/0.9 request was rejected due to HTTP/1.0 support not being configured. | ||
| const std::string LowVersion = "low_version"; | ||
| // The request was rejected due to the Host: or :authority field missing | ||
| const std::string MissingHost = "missing_host_header"; | ||
| // The request was rejected due to the request headers being larger than the configured limit. | ||
| const std::string RequestHeadersTooLarge = "request_headers_too_large"; | ||
| // The request was rejected due to the Path or :path header field missing. | ||
| const std::string MissingPath = "missing_path_rejected"; | ||
| // The request was rejected due to using an absolute path on a route not supporting them. | ||
| const std::string AbsolutePath = "absolute_path_rejected"; | ||
| // The request was rejected because path normalization was configured on and failed, probably due | ||
| // to an invalid path. | ||
| const std::string PathNormalizationFailed = "path_normalization_failed"; | ||
| // The request was rejected because it attempted an unsupported upgrade. | ||
| const std::string UpgradeFailed = "upgrade_failed"; | ||
| // The request was rejected by the router filter because there was no route found. | ||
| const std::string RouteNotFound = "route_not_found"; | ||
| // A direct response was generated by the router filter. | ||
| const std::string DirectResponse = "direct_response"; | ||
| // The request was rejected by the router filter because there was no cluster found for the | ||
| // selected route. | ||
| const std::string ClusterNotFound = "cluster_not_found"; | ||
| // The request was rejected by the router filter because the cluster was in maintenance mode. | ||
| const std::string MaintenanceMode = "maintenance_mode"; | ||
| // The request was rejected by the router filter because there was no healthy upstream found. | ||
| const std::string NoHealthyUpstream = "no_healthy_upstream"; | ||
| // The upstream response timed out | ||
| const std::string UpstreamTimeout = "upstream_response_timeout"; | ||
| // The final upstream try timed out | ||
| const std::string UpstreamPerTryTimeout = "upstream_per_try_timeout"; | ||
| // The upstream connection was reset before a response was started. This | ||
| // will generally be accompanied by details about why the reset occurred. | ||
| const std::string EarlyUpstreamReset = "upstream_reset_before_response_started"; | ||
| // The upstream connection was reset after a response was started. This | ||
| // will generally be accompanied by details about why the reset occurred but | ||
| // indicates that original "success" headers may have been sent downstream | ||
| // despite the subsequent failure. | ||
| const std::string LateUpstreamReset = "upstream_reset_after_response_started"; | ||
| // TODO(#6542): continue addding values for sendLocalReply use-cases | ||
| }; | ||
|
|
||
| typedef ConstSingleton<ResponseCodeDetailValues> ResponseCodeDetails; | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Those look great, thanks, but you're effectively rewriting even the existing
Proxy-Statustypes, so what's your plan in regards to that header? Using corresponding standard types and then using those values in thedetailsfield or completely ignoring standard types and only usinghttp_{request,response}_errorwith those values indetails? In either case, I think you might need astd::pair(or perhaps evenstd::tuple) here, instead of only strings.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 think when we implement proxy-status these could be extended. I could do a one off with today's proxy-status codes but I really don't want to sign up for keeping it up to date and I'd prefer to not add code which is going to bitrot as the IETF makes forward progress. I don't think creating this without the tuple creates more work for when we implement proxy-status, and it might reduce it (by filling in the details field)