[PATCH 2 of 3] Headers filter: add "add_trailer" directive
Maxim Dounin
mdounin at mdounin.ru
Fri Jun 2 16:20:39 UTC 2017
Hello!
On Fri, Jun 02, 2017 at 02:10:07AM -0700, Piotr Sikora via nginx-devel wrote:
> Hey Maxim,
>
> > This introduces a layering violation between the headers filter
> > and the chunked filter.
>
> I moved trailer generation to headers filter, let me know if that works for you.
>
> Unfortunately, because of that change, trailers are evaluated earlier
> in the process, and some variables from body filters that run after
> headers filter (like $gzip_ratio) are not usable anymore.
This looks better. If there is a need to evaluate trailers later,
a separate module could be added to a later stage, like it is done
with ngx_http_range_header_filter vs. ngx_http_range_body_filter.
[...]
> > Predicting conditions which will result in header-only response
> > looks really fragile. As well as checks for chunked transfer
> > encoding.
>
> Sending "Trailer" header in responses that cannot have response body
> is known to result in interoperability issues, so I'd rather leave it,
> see:
> https://github.com/nodejs/node/issues/2842
So may be not generating "Trailer" is a way to go?
It doesn't seem to be really needed.
(Just for the record, with the first patch fixed to avoid using
chunked with HTTP/1.0, the "Trailer" header is expectedly still
added with HTTP/1.0. This confirms the idea that the approach
choosen is somewhat fragile.)
[...]
> > Note that at this point we do not know if the trailer in question
> > is going to be present in the particular response or not, as
> > trailers with empty values are not returned (and this is often
> > used to only return some headers in some responses, at least with
> > add_header).
>
> But we know that it might be present.
>
> "Trailer" header is an indicator.
The question is: if we need this indicator to be sent to a
particular client.
For example, if you are using trailers to pass additional logging
information to your own frontends, and use something like
geo $mine {
127.0.0.1/8 1;
}
map $mine $x_request_time {
1 $request_time;
}
add_trailer X-Response-Time $x_request_time;
to send the information to your frontends, but not other clients,
you probably don't want the X-Response-Time trailer to be
indicated to other clients.
> > It might be a better idea to avoid generating the
> > "Trailer" header automatically and let users to control this with
> > add_header instead, and/or introduce an option to control this.
>
> That sounds like a terrible idea, which will result in always missing
> "Trailer" header.
Acutally I don't see how it's a problem, given that "Trailer" is
not something required. Moreover, it seems to be not needed or
even harmful in most of the use cases discussed.
[...]
--
Maxim Dounin
http://nginx.org/
More information about the nginx-devel
mailing list