Fastly allows to customise vcl_error subroutine. However, If I override it (e.g.
sub vcl_error {
#FASTLY error
set obj.http.Custom-Header = "foo-bar";
return(deliver);
}
), original response body with error cause (e.g. "first byte timout") is lost.
Is it possible to obtain a cause, so I can add it to additional some header or syntetic body
The vcl_error subroutine is triggered either implicitly by Fastly (see the documentation for examples of when it does this) or explicitly using the error statement.
Within vcl_error the obj.status and obj.response variables provide information about the nature of the error.
If you're explicitly triggering vcl_error, then from within the subroutine you're invoking the error statement you should set a custom HTTP header on an object that you can read back from within vcl_error.
For example, the req object is available to all subroutines so you could use req.http.{NAME}) to store off any contextual error information you want to use as part of your synthetic error response.
One caveat with persisting data in this fashion is that you can't persist data across certain boundaries, such as the move from a subroutine on a 'fetching node' to a 'delivery node' (see clustering for details of what the difference between fetching/delivery nodes).
Off the top of my head (see also: https://www.integralist.co.uk/posts/fastly-varnish/#breadcrumb-trail) I believe if you're invoking error from vcl_fetch you'll need to persist the data to the beresp object and not req. Varnish will copy beresp to the obj object that is exposed to the vcl_error subroutine.
If you have any other questions or concerns, then please reach out to support@fastly.com who will be happy to help.
Please also refer to the Fastly 'Developer Hub' which has a bunch of resources on Varnish and VCL that might be useful to you.
