Hello!
On Wed, Jul 3, 2013 at 5:37 PM, Marcus Clyne wrote:
>> If the subrequest uses the upstream mechanism, wouldn't it be safe to just
>> close the socket of upstream's connection? I'm assuming there would be an
>> entry in the error log, but is there anything harmful that could come from
>> it
El 03/07/13 20:59, Marcus Clyne escribió:
El 03/07/13 08:54, Maxim Dounin escribió:
Hello!
On Wed, Jul 03, 2013 at 04:34:26AM +0400, Marat Dakota wrote:
Nobody knows?
On Sun, Jun 30, 2013 at 3:04 PM, Marat Dakota
wrote:
Hi,
I am parsing a subrequest's body as it arrives. At some point
El 03/07/13 08:54, Maxim Dounin escribió:
Hello!
On Wed, Jul 03, 2013 at 04:34:26AM +0400, Marat Dakota wrote:
Nobody knows?
On Sun, Jun 30, 2013 at 3:04 PM, Marat Dakota wrote:
Hi,
I am parsing a subrequest's body as it arrives. At some point I could
decide that the subrequest's body is
Yichun, thanks for your notes.
Even though they are not as optimistic as I would like them to be :).
--
Marat
On Thu, Jul 4, 2013 at 12:00 AM, Yichun Zhang (agentzh)
wrote:
> Hello!
>
> On Wed, Jul 3, 2013 at 6:17 AM, Marat Dakota wrote:
> > Are there any adequately hardcore methods to close
Hello!
On Wed, Jul 3, 2013 at 6:17 AM, Marat Dakota wrote:
> Are there any adequately hardcore methods to close subrequest's connection?
> I mean, what steps should be done internally?
>
I was also thinking hard about this problem when I was implementing
the "light thread" model in our ngx_lua mo
details: http://hg.nginx.org/nginx/rev/af60a210cb78
branches:
changeset: 5261:af60a210cb78
user: Ruslan Ermilov
date: Wed Jul 03 12:04:13 2013 +0400
description:
Upstream: updated list of ngx_event_connect_peer() return values.
ngx_http_upstream_get_keepalive_peer() may return NGX_D
Hello!
On Tue, Jul 2, 2013 at 7:35 AM, Jeff Kaufman wrote:
> In a header filter, to remove a filter that's already been set, I see
> two options:
>
> 1. set the header's hash to 0
For *response* headers, this approach is recommended.
> 2. actually delete the header from r->headers_out
>
> The s
Hello!
On Wed, Jul 03, 2013 at 04:48:29PM +0200, Florian S. wrote:
> Hi together!
>
> I'm having occasionally trouble with worker processes left
> and nginx stopping handling signals (HUP and even TERM) in general.
>
> Upon reconfigure signal, the log shows four new processes being
> spawned,
Hi together!
I'm having occasionally trouble with worker processes left and
nginx stopping handling signals (HUP and even TERM) in general.
Upon reconfigure signal, the log shows four new processes being spawned,
while the old four processes are shutting down:
> [notice] 5159#0: using the
Hi Maxim,
Are there any adequately hardcore methods to close subrequest's connection?
I mean, what steps should be done internally?
For now, I'm just setting a flag in subrequest's context and just ignoring
the data in subrequest's body filter depending on this flag. It is ok, but
if there is a r
Hello!
On Wed, Jul 03, 2013 at 04:34:26AM +0400, Marat Dakota wrote:
> Nobody knows?
>
>
> On Sun, Jun 30, 2013 at 3:04 PM, Marat Dakota wrote:
>
> > Hi,
> >
> > I am parsing a subrequest's body as it arrives. At some point I could
> > decide that the subrequest's body is not well-formed. I w
details: http://hg.nginx.org/nginx/rev/e088695737c3
branches:
changeset: 5260:e088695737c3
user: Vladimir Homutov
date: Fri Jun 28 17:24:54 2013 +0400
description:
Core: consolidated log-related code.
The stderr redirection code is moved to ngx_log_redirect_stderr().
The opening of
12 matches
Mail list logo
