# HG changeset patch
# User Piotr Sikora
# Date 1466735480 25200
# Thu Jun 23 19:31:20 2016 -0700
# Node ID a96187a9806536ab2a8bf3fa7f7b659cf5d3ff13
# Parent 6f69e3c0f780e29bca752fc1f938f4a459a1ec59
HTTP: add support for trailers in HTTP responses.
Example:
ngx_table_elt_t *h;
h =
Hey Shuxin,
> I took some time to read your code, I believe I fully understand your
> code at this moment.
> My implementation is slightly differently from yours, and we have different
> use-cases.
Thanks!
> Here is my $0.02 value of comment to your code (cosmetic wise):
> - the v
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 time
Hey Shuxin,
> How do you manage to tackle this scenario without changing your existing
> code:
>
> 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 o
Hey Maxim,
> Would adding r->trailers_emit (or r->expect_trailers, whichever you
> prefer) make you happy?
Ping.
Best regards,
Piotr Sikora
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Hello!
On Thu, Jun 30, 2016 at 12:56:50PM -0700, Piotr Sikora wrote:
> Hey Maxim,
>
> > Would adding r->trailers_emit (or r->expect_trailers, whichever you
> > prefer) make you happy?
>
> Ping.
I'm not convinced this feature is needed at all. It looks more
like a Google-specific experiment,
Hey Maxim,
> I'm not convinced this feature is needed at all. It looks more
> like a Google-specific experiment, and this is not something I
> would like to see in nginx code.
Wait, what? Are you talking about trailers as defined in RFC7230 (and
previously in RFC2616 from 1999, when Google barel
Hello!
On Wed, Jul 06, 2016 at 02:02:19PM -0700, Piotr Sikora wrote:
> Hey Maxim,
>
> > I'm not convinced this feature is needed at all. It looks more
> > like a Google-specific experiment, and this is not something I
> > would like to see in nginx code.
>
> Wait, what? Are you talking about t
Hey Maxim,
> And these 3 people are the only people asking/commenting about
> trailers during the whole nginx history, AFAIR. And none of them
> provided any real-world use for trailers.
That's true... Wesley, Shuxin, would you mind sharing your use cases?
> On the other hand, your
> motivation
Hello!
On Thu, Jul 07, 2016 at 01:08:46PM -0700, Piotr Sikora wrote:
[...]
> Furthermore, like you previously noted, official gRPC clients & server
> are using HTTP/2, so there is absolutely no Google-agenda in pushing
> HTTP/1.1 trailers, other than me wanting to add proper support for
> traile
Hey Maxim,
> So the question remains: are there any real-world use cases? May
> be someone will be able to provide some.
It's a chicken-and-egg problem. It's hard to use a feature that's not
supported by one of the most popular web servers.
> Without real-world use cases I don't think this shou
Hello!
On Wed, Jul 13, 2016 at 10:25:57AM -0700, Piotr Sikora wrote:
> > So the question remains: are there any real-world use cases? May
> > be someone will be able to provide some.
>
> It's a chicken-and-egg problem. It's hard to use a feature that's not
> supported by one of the most popular
Hey Maxim,
> I'm talking about trailers in general (though it's more about
> requests than responses). Normal request (and response)
> processing in nginx assumes that headers are processed before the
> body, and adding trailers (which are headers "to be added later")
> to the picture are likely
Speaking of trailers: we had couple of use cases for HTTP trailers, most of
them were around streaming data to user.
For example, when webpage is generated we send headers and part of the
body(usually up to ``) almost immediately, but then we start querying
all the micro services for the conten
Hello!
On Wed, Jul 20, 2016 at 03:34:46PM -0700, Alexey Ivanov wrote:
> Speaking of trailers: we had couple of use cases for HTTP
> trailers, most of them were around streaming data to user.
>
> For example, when webpage is generated we send headers and part
> of the body(usually up to ``) alm
> On Jul 20, 2016, at 6:23 PM, Maxim Dounin wrote:
>
> Hello!
>
> On Wed, Jul 20, 2016 at 03:34:46PM -0700, Alexey Ivanov wrote:
>
>> Speaking of trailers: we had couple of use cases for HTTP
>> trailers, most of them were around streaming data to user.
>>
>> For example, when webpage is gene
Hello!
On Wed, Jul 20, 2016 at 06:33:11PM -0700, Alexey Ivanov wrote:
>
> > On Jul 20, 2016, at 6:23 PM, Maxim Dounin wrote:
> >
> > Hello!
> >
> > On Wed, Jul 20, 2016 at 03:34:46PM -0700, Alexey Ivanov wrote:
> >
> >> Speaking of trailers: we had couple of use cases for HTTP
> >> trailers,
Hello!
On Sun, Jun 26, 2016 at 04:13:15PM -0700, Piotr Sikora wrote:
> # HG changeset patch
> # User Piotr Sikora
> # Date 1466735480 25200
> # Thu Jun 23 19:31:20 2016 -0700
> # Node ID a96187a9806536ab2a8bf3fa7f7b659cf5d3ff13
> # Parent 6f69e3c0f780e29bca752fc1f938f4a459a1ec59
> HTTP: ad
Hey Maxim,
> What's the goal? Any real-world use for this?
For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
transport protocol.
> As far as I understand the patch, this will cause chunked encoding
> to be used for all responses to a client which supports trailers.
> This certa
Hi, Piotr:
I'm wondering why not just change the ngx_http_chunked_filter_module.c?
or add a module inserted right after the chunked-filter-module?
Shuxin
On 06/27/2016 07:37 AM, Piotr Sikora wrote:
Hey Maxim,
What's the goal? Any real-world use for this?
On 06/27/2016 06:45 AM, Maxim
Hey Shuxin,
>I'm wondering why not just change the ngx_http_chunked_filter_module.c?
> or add a module inserted right after the chunked-filter-module?
Hmm...? I'm confused by your comment.
This patch modifies 3 files:
- parsing of "TE" header is done in ngx_http_request.c,
- HTTP/1.1 trailer
Hello!
On Mon, Jun 27, 2016 at 07:37:31AM -0700, Piotr Sikora wrote:
> > What's the goal? Any real-world use for this?
>
> For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
> transport protocol.
Last time I checked gRPC wasn't able to talk HTTP/1.1, and
therefore wasn't able
Hi, Piotr and Maxim:
> to Maxim's question about "does trailer has real-world use" first.
At least we do, some info is available only after the entire body is
sent. Trailer is a viable and convenient
solution for that matter, albeit it is not the only solution for it. I
cannot "leak" more inf
Hey Maxim,
> Last time I checked gRPC wasn't able to talk HTTP/1.1, and
> therefore wasn't able to work with nginx at all. So no real-world
> use for now, right?
Official clients & servers support only HTTP/2, but gRPC protocol can
be layered on top of HTTP/1.1 with trailers, so it's up to the
i
Hey Shuxin,
> As far as I can understand, your change is just to add trailer headers
> (not including the part that paring incoming
> trailer header from upstream, or merge the incoming trailer and generated
> trailer). If that is correct, you just need
> to add "trailer: hdr1,hdr2... hdrn" to
Hi, Piotr:
I took some time to read your code, I believe I fully understand
your code at this moment.
My implementation is slightly differently from yours, and we have
different use-cases.
Here is my $0.02 value of comment to your code (cosmetic wise):
- the verb "support" in "
26 matches
Mail list logo
