Hello!
On Fri, Oct 25, 2013 at 06:54:43AM +0530, Ashwini Venkatesh wrote:
> Hello!
> I wanted to know how is the chain of execution of body filters.
> In my case the header filter of the same filter is executed but not the
> body filter. Does it depend on the execution of previous body filters?
Hello!
On Thu, Oct 24, 2013 at 02:22:02PM -0700, Piotr Sikora wrote:
> # HG changeset patch
> # User Piotr Sikora
> # Date 1382649516 25200
> # Thu Oct 24 14:18:36 2013 -0700
> # Node ID c677648001a2efc383e97229251a5f1df8407122
> # Parent e6a1623f87bc96d5ec62b6d77356aa47dbc60756
> Core: st
This is a response to rev 4746 which removed ETags. 4746 removes the ETag field
from the header in all instances where content is modified by the web server
prior to being sent to the requesting client. This is far more stringent than
required by the HTTP spec.
The HTTP spec requires that strict E
Hi Aaron,
I disagree with your patch... While retaining weak ETags in case of
gzip/gunzip modules is correct, other modules are modifying the
content and weak ETags should be removed from responses processed by
them.
Best regards,
Piotr Sikora
___
nginx
Hey Maxim,
> Any specific reason to? It doesn't seems to fail / produce any
> problems, and may even start working eventually.
On the contrary, the call used to succeed (tested with Linux 3.2),
but recently started failing (tested with Linux 3.9), which results
in errors produced during binary u
Hello!
I've noticed a request hang due to an issue in
ngx_http_gzip_filter_module's output body filter. Basically when the
downstream connection is slow to write to, a write event can trigger a
call of ngx_http_output_filter(r, NULL) but ngx_gzip's body filter
does not pass the NULL chain link to
Hello!
On Fri, Oct 25, 2013 at 05:16:24PM -0700, Yichun Zhang (agentzh) wrote:
> Hello!
>
> I've noticed a request hang due to an issue in
> ngx_http_gzip_filter_module's output body filter. Basically when the
> downstream connection is slow to write to, a write event can trigger a
> call of ngx
Hello!
On Fri, Oct 25, 2013 at 03:57:24PM -0700, Piotr Sikora wrote:
> Hey Maxim,
>
> > Any specific reason to? It doesn't seems to fail / produce any
> > problems, and may even start working eventually.
>
> On the contrary, the call used to succeed (tested with Linux 3.2),
> but recently star
Hello!
On Fri, Oct 25, 2013 at 6:48 PM, Maxim Dounin wrote:
>
> Could you please elaborate how do you see the problem? In 1.5.6
> this probably can be triggered with incomplete upstream response,
> which intentionally results in no last buffer send, but with such
> responses nothing is guaranteed
Hello!
On Fri, Oct 25, 2013 at 10:55 PM, Yichun Zhang (agentzh) wrote:
>
> This is triggered by my own (3rd-party) module, ngx_lua. This module
> provides a ngx.flush(true) API function that flushes out all pending
> output data and *wait* (nonblockingly) until all outputs are *indeed*
> flushed o
10 matches
Mail list logo