[nginx] Typo.
details: http://hg.nginx.org/nginx/rev/58956c644ad0 branches: changeset: 5924:58956c644ad0 user: Maxim Dounin date: Fri Nov 28 16:57:23 2014 +0300 description: Typo. diffstat: src/core/ngx_crypt.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff --git a/src/core/ngx_crypt.c b/src/core/ngx_crypt.c --- a/src/core/ngx_crypt.c +++ b/src/core/ngx_crypt.c @@ -66,7 +66,7 @@ ngx_crypt_apr1(ngx_pool_t *pool, u_char size_t saltlen, keylen; ngx_md5_t md5, ctx1; -/* Apache's apr1 crypt is Paul-Henning Kamp's md5 crypt with $apr1$ magic */ +/* Apache's apr1 crypt is Poul-Henning Kamp's md5 crypt with $apr1$ magic */ keylen = ngx_strlen(key); ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] Fixed post_action to not trigger "header already sent" a...
details: http://hg.nginx.org/nginx/rev/c76d851c5e7a
branches:
changeset: 5925:c76d851c5e7a
user: Maxim Dounin
date: Fri Nov 28 16:57:50 2014 +0300
description:
Fixed post_action to not trigger "header already sent" alert.
The alert was introduced in 03ff14058272 (1.5.4), and was triggered on each
post_action invocation.
There is no real need to call header filters in case of post_action,
so return NGX_OK from ngx_http_send_header() if r->post_action is set.
diffstat:
src/http/ngx_http_core_module.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diffs (14 lines):
diff --git a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c
+++ b/src/http/ngx_http_core_module.c
@@ -1973,6 +1973,10 @@ ngx_http_send_response(ngx_http_request_
ngx_int_t
ngx_http_send_header(ngx_http_request_t *r)
{
+if (r->post_action) {
+return NGX_OK;
+}
+
if (r->header_sent) {
ngx_log_error(NGX_LOG_ALERT, r->connection->log, 0,
"header already sent");
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] Write filter: fixed handling of sync bufs (ticket #132).
details: http://hg.nginx.org/nginx/rev/08bfc7188a41
branches:
changeset: 5926:08bfc7188a41
user: Maxim Dounin
date: Fri Nov 28 16:58:39 2014 +0300
description:
Write filter: fixed handling of sync bufs (ticket #132).
diffstat:
src/http/ngx_http_write_filter_module.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diffs (51 lines):
diff --git a/src/http/ngx_http_write_filter_module.c
b/src/http/ngx_http_write_filter_module.c
--- a/src/http/ngx_http_write_filter_module.c
+++ b/src/http/ngx_http_write_filter_module.c
@@ -48,7 +48,7 @@ ngx_int_t
ngx_http_write_filter(ngx_http_request_t *r, ngx_chain_t *in)
{
off_t size, sent, nsent, limit;
-ngx_uint_t last, flush;
+ngx_uint_t last, flush, sync;
ngx_msec_t delay;
ngx_chain_t *cl, *ln, **ll, *chain;
ngx_connection_t *c;
@@ -62,6 +62,7 @@ ngx_http_write_filter(ngx_http_request_t
size = 0;
flush = 0;
+sync = 0;
last = 0;
ll = &r->out;
@@ -105,6 +106,10 @@ ngx_http_write_filter(ngx_http_request_t
flush = 1;
}
+if (cl->buf->sync) {
+sync = 1;
+}
+
if (cl->buf->last_buf) {
last = 1;
}
@@ -157,6 +162,10 @@ ngx_http_write_filter(ngx_http_request_t
flush = 1;
}
+if (cl->buf->sync) {
+sync = 1;
+}
+
if (cl->buf->last_buf) {
last = 1;
}
@@ -188,7 +197,7 @@ ngx_http_write_filter(ngx_http_request_t
&& !(c->buffered & NGX_LOWLEVEL_BUFFERED)
&& !(last && c->need_last_buf))
{
-if (last || flush) {
+if (last || flush || sync) {
for (cl = r->out; cl; /* void */) {
ln = cl;
cl = cl->next;
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Adding a delay in body filter response
Sorry if this is not the place to ask this or if this has been asked before (google hasn't been helpful), but I'm unsure of how to proceed with this problem. I am developing a body filter module that processes html and has to do a process in the middle of sending a response that can take upwards of a couple seconds. So for example, the first half of the HTML gets sent immediately, a process happens and eventually finishes, then second half gets sent (the contents of the second half being dependent on the results of the process). How to I get a body filter to "wait" for a bit and then continue sometime later? The signal/flag/whatever to continue could come from a timer event or elsewhere. I'm looking for a non-blocking solution obviously. I'm using nginx as a proxy if that makes any difference so the HTML doesn't originate on this server. And yes, it's a bit of a weird use case. Thanks, Tod.___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Request hang when cache_lock is used in subrequests
Hi Maxim! On Thu, Nov 27, 2014 at 7:31 AM, Maxim Dounin wrote: > Yichun, I've spent some time looking in this, and I don't see how > it can cause infinite hang at least with stock nginx modules. It > certainly can cause suboptimal behaviour though, both with proxy > cache locks and with AIO. > You're right. I'm not using the stock nginx modules nor the stock subrequest model :P > Here are two patches to address this (and also logging issues with > subrequests): > I've just confirmed that you patches fix my issue. Thank you very much! Best regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Adding a delay in body filter response
Hello! On Fri, Nov 28, 2014 at 2:46 PM, Tod Baudais wrote: > I am developing a body filter module that processes html and has to do a > process in the middle of sending a response that can take upwards of a > couple seconds. What is this "process" exactly? Is it CPU-bound computation or just a (nonblocking) IO operation? > So for example, the first half of the HTML gets sent > immediately, a process happens and eventually finishes, then second half > gets sent (the contents of the second half being dependent on the results of > the process). If the "process" is an IO operation, this looks trivial if it is implemented as a content handler instead of a body filter. > How to I get a body filter to "wait" for a bit and then > continue sometime later? Alas. The nginx output body filter does not provide a "wait" mode by its design. To make it actually wait, we need to cheat a bit by exhausting the "busy bufs" of the content handler (so as to make it stop sending more bufs in non-buffered mode). That's the only way I'm aware of. (Feel free to prove me wrong.) And the closest thing in the stock nginx distribution is the limit_rate mechanism which can serve as an example. But again, this is complicated, so be careful :) Regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
