[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses
shuxinyang.oss at gmail.com
Tue Jun 28 00:56:37 UTC 2016
> It's "trailer support" for the web serving part of NGINX, just not proxying.
>> - the "get" in "ngx_http_chunked_get_trailers" is sort of misleading.
>> The "get" here actually
>> means "generate". I thought you are looking for a existing buffer.
> That function name got changed a few times, since I cannot find one
> that I would be 100% happy with... Any suggestions?
I hope you don't call me "make fuss about nothing":-). Being an
impatient code reader,
I usually take a glimpse the code by reading comment and/or function,
what it tries to do, and stitch them together into a big picture.
the verb "get" did confuse me yesterday and this morning when I took a
I would say "create" or "generate" (or something else) would be better.
Anyway, naming is not big deal, maybe I (and other impatient code
reader) need change:-)
>> Now go back to the long list of trailer support, I believe it needs to
>> cover at least:
>> 1) generate trailer headers and sent to downstream/visitor as you just
>> 2) reverse proxy propagate trailer headers from upstream, which needs
>> 2.0 parse the incoming trailer header, both considering the body is
>> buffered and not buffered,
>> 2.1. make the incoming trailer accessible via variable after content
>> 2.2. if response body is is not buffered, combine incoming trailer
>> header with the generated headers.
>> 2.3. convert incoming trailer to regular header if response body is
>> 3|4|..|n) other features.
>> I think 2.x is much harder than 1). I only implement 1) and 2.0) and
>> 2.1). While implement 2.1), I left some
>> room for 2.2 and 2.3 for the future. Now that you have plan for 2.x as your
>> email suggests, wouldn't it
>> be nice to submit these code first, and then go ahead with the code of 1). I
>> believe to support 2.2 or 2.3,
>> your existing code in chunk module needs lots of change.
> I don't see how anything you listed in 2.x would require modifications
> to the code I submitted... Actually, everything you listed should be
> handled in upstream and/or proxy modules, not chunking module, and it
> could easily use the API (r->headers_out.trailers) I want to add in
> this commit.
How do you manage to tackle this scenario without changing your existing
backend server responses with trailer "lol = 123", and you define
the same trailer,
"lol = $haha" in *.conf. You have two options as to how to combine them:
either override the
one from origin, and override the one from your *.conf. It seems to me
chunk-module is again a best place for such change.
> Best regards,
> Piotr Sikora
> nginx-devel mailing list
> nginx-devel at nginx.org
More information about the nginx-devel