Add ability to suppress Linkerd error response body and header #2201
Comments
|
👋 @chrismikehogan, Thanks for filing this. FWIW, there is a config parameter called |
|
I saw that flag in the configuration docs, but it wasn't obvious to me that it would do what I wanted, in addition to what the docs said it does:
We definitely don't wan't the behavior described in the docs, even if it got us the suppressed error responses. |
|
Ah, that's right, it also gets applied to inbound requests as well so that wouldn't work. |
|
Thinking about this a little bit more, do you think it would be better to mimic what Linkerd does to the The config parameter could definitely help but I feel that adding more implicit behavior through a header might increase the complexity of Linkerd's per-request handler. I am thinking that an error response with that much verbosity might not be as useful anyway and so it might be better to just truncate it. WDYT? /cc @adleong |
|
Truncating the response sounds great to me |
|
Truncating would work perfectly for us as well, even more so if the level of truncation could be controlled. We could take or leave the concept debug header adding additional info. |
|
It's a great idea to truncate a response body in case of a mesh error (request timeout or bad routing, etc) or just unify all errors to have a generic error body for all cases. It will much simplify client side because now it's a headache to handle all this different structures of a response body for each error. |
…KB, which can be used to limit the body of a http error response. This is different from the already existing maxResponseKB which limits the body of any http response, error or not. By default maxErrResponseKB has the same value as maxResponseKB which is 5MB. (#2291) Here https://api.linkerd.io/1.6.1/linkerd/index.html#http-1-1-protocol, I've found two http config options here which can be used to truncate large headers or response bodies as requested for #2201: maxHeadersKB | 8 | The maximum size of all headers in an HTTP message. maxResponseKB | 5120 | The maximum size of a non-chunked HTTP response payload. maxHeadersKB was already implemented and supported for l5d-err headers, I've done some tests with large dtabs and the l5d-err headers are truncated to the size specified by maxHeadersKB. maxResponseKB was only parsed by HttpConfig.scala but was not implemented/supported by the rest of the Linderd code. This pull request adds support for maxResponseKB limit when constructing responses containing l5d-err header, what it does it just truncates the error response body to the limit specified by the maxResponseKB. The option name is somehow misleading, as one might expected the truncation to be done for the http response packet size instead of the http response body size, more precisely for error response body size. With this fix someone setting the config maxResponseKB / hparam.MaxResponseSize to a value lower than the 5120 default, will obtain truncation of the err response body size. IMO A better approach would be to have two new config options specific to err headers and err response bodies, called maxErrHeadersKB and maxErrResponseKB. In this way users would benefit by the standard limits for headers and reponses and also have a much finer control over err headers and err responses. Signed-off-by: dst4096 <dst4096@gmail.com>
Issue Type:
Problem
We are trying to use Linkerd's dtab feature to build very large, dynamic routing tables. The goal to use Linkerd (instead of, e.g. Consul) to control which versions of which applications get routed to when a a request for a particular service is received.
This requires us to dynamically build most of our dtab, and requires that the dtab have an explicit dentry for every service in our eco system. E.g.:
This means that our dtab will get very large! The example I'm working with at the moment is 1811 lines long, and 143kb.
When linkerd errors in some way (say when a requested service is not found), it currently 502s and sends back an error message that contains, among other things, the entire dtab in both the body and a response header.
Fortunately, Linkerd appears to truncate the response header field instead of blowing up. But I think it would be useful to be able to suppress this verbose response by default, exposing it only if the client provided a debug header.
Possible solution
Provide a configuration option to suppress verbose error responses by default.
Add support for a debug header that results in the verbose error response.
The text was updated successfully, but these errors were encountered: