it well be locked in the case of multiple threads.<br><br><div class="gmail_quote">2012/7/20 <span dir="ltr"><<a href="mailto:nginx-devel-request@nginx.org" target="_blank">nginx-devel-request@nginx.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send nginx-devel mailing list submissions to<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:nginx-devel-request@nginx.org">nginx-devel-request@nginx.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:nginx-devel-owner@nginx.org">nginx-devel-owner@nginx.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of nginx-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: various body filter questions (Maxim Dounin)<br>
2. a little bug in ngx_event_expire_timers (Joy zhou)<br>
3. Re: a little bug in ngx_event_expire_timers (Ruslan Ermilov)<br>
4. [nginx] svn commit: r4757 - trunk/src/http/modules (<a href="mailto:ru@nginx.com">ru@nginx.com</a>)<br>
5. Re: a little bug in ngx_event_expire_timers (Pass86)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 19 Jul 2012 17:52:24 +0400<br>
From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
Subject: Re: various body filter questions<br>
Message-ID: <<a href="mailto:20120719135224.GC31671@mdounin.ru">20120719135224.GC31671@mdounin.ru</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hello!<br>
<br>
On Thu, Jul 19, 2012 at 10:48:59AM +0100, Robert Lemmen wrote:<br>
<br>
> hi everyone,<br>
><br>
> I need to run an nginx with a custom body filter, for the sake of<br>
> argument let's say I want to replace "robert" with "bob" in every file<br>
> that ends with ".txt". I played around a bit and looked at the various<br>
> tutorials and documentation on the net. I have managed to get it<br>
> basically working, but am looking for your input to get it "correct":<br>
><br>
> a) I create a module context and store it via ngx_http_set_ctx(). how do<br>
> I clean it up? or do I not need to?<br>
<br>
Usually you don't need to. If you really want for some reason,<br>
you may use ngx_http_set_ctx() with NULL.<br>
<br>
> does everything allocated with<br>
> ngx_pcalloc(r->pool, ...) get freed when the request is sorted?<br>
<br>
Yes. Everything allocated from a pool is freed on the pool<br>
destruction.<br>
<br>
> b) I would like to handle HEAD requests as well, but I can't just do it<br>
> with a filter. In the header filter I don't have the actual data in the<br>
> file, so I can't do the substitutions, so I don't know what the<br>
> content-length will be. what to do? I was thinking doing a GET<br>
<br>
Usual aproach is to just remove Content-Length header from an<br>
answer. As even with GET you can't forecast response length<br>
before you've done processing full response, which in turn means<br>
your module will just don't work with anything but small<br>
responses.<br>
<br>
[...]<br>
<br>
> c) in the body filter, I want to read the buffer chain and modify it or<br>
> create a new one. but I don't get all the details of the buffer chain.<br>
> assuming "ngx_chain_t *in" as a parameter of the filter:<br>
> - if in->next != 0 (and so on), does that mean these buffers are parts<br>
> of the actual file? so e.g. in->buf could hold the first half of teh<br>
> file and in->next->buf the second half?<br>
<br>
Not file, response. Otherwise yes, there may be more than one<br>
buffer in a chain passed to a body filter. Moreover, it may be<br>
more than one call to a body filter. You have to handle all<br>
buffers in the input chain(s) passed to your body filter.<br>
<br>
> - what are the semantics of the different fields in in->buf? what's the<br>
> difference between pos/last and start/end? what do the different flags<br>
> (temporary, memory, mmap, recycled, in_file, flush, sync) mean?<br>
<br>
The pos/last are bounds of memory used in a buffer, start/end -<br>
memory region allocated. Various flags specify various buffer<br>
properties, try looking code for details.<br>
<br>
> - what's the difference between last_buf, last_in_chain? is it not the<br>
> same as in->next == 0?<br>
<br>
The last_in_chain flag marks last buffer of a subrequest response,<br>
last_buf - last buffer in a main request response. It's not the<br>
same as in->next == NULL as the latter means nothing, see above.<br>
<br>
> - it might be easier for me to read the buffers and create new ones,<br>
> rather than changing the existing ones. do I need to do any sort of<br>
> cleanup?<br>
<br>
Yes. If you don't pass original buffer to a next filter and<br>
instead copy it's contents you have to mark buffer as sent by<br>
moving b->pos to b->last. Failure to do so will result in hang<br>
on large responses as eventually underlying module will run out of<br>
buffers and will wait for previously passed buffers to be sent.<br>
<br>
> - are the buffers always complete? how would I know? I assume that if I<br>
> download a 10GB file nginx doesn't just copy it into memory...<br>
<br>
Single buffer chain passed to a body filter doesn't necessary<br>
represent full response.<br>
<br>
Number and size of buffers used to copy files to memory (once one<br>
of a filters needs it) may be controlled with output_buffers<br>
directive, see <a href="http://nginx.org/r/output_buffers" target="_blank">http://nginx.org/r/output_buffers</a>.<br>
<br>
> - how does sendfile work in nginx? if I do a body filter I of course<br>
> need to make sure sendfile is never used.<br>
<br>
As long as buffers aren't with file-based content sendfile is not<br>
used. You shouldn't care about this as long as you correctly<br>
modify buffer chain(s).<br>
<br>
Maxim Dounin<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 20 Jul 2012 12:11:51 +0800<br>
From: Joy zhou <<a href="mailto:yizhou136@gmail.com">yizhou136@gmail.com</a>><br>
To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
Subject: a little bug in ngx_event_expire_timers<br>
Message-ID:<br>
<CAPw8Emfgs43CydaC6mafOgFHrRKD=<a href="mailto:DvqwPdBFQJY7KrUusvM3w@mail.gmail.com">DvqwPdBFQJY7KrUusvM3w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
hi everyone:<br>
<br>
I have found a little bug at method ngx_event_expire_timers of the file<br>
"src/event/ngx_event_timer.c "<br>
<br>
<br>
84 for ( ;; ) {<br>
85<br>
86 ngx_mutex_lock(ngx_event_timer_mutex);<br>
87<br>
88 root = ngx_event_timer_rbtree.root;<br>
89<br>
90 if (root == sentinel) {<br>
91 return;<br>
92 }<br>
<br>
[...]<br>
}<br>
<br>
The above code should add "ngx_mutex_unlock(ngx_event_timer_mutex);" at<br>
90 line,<br>
Because the ngx_event_timer_mutex has locked at begin , but returned<br>
without unlock , is it right?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120720/cbcae94d/attachment-0001.html" target="_blank">http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120720/cbcae94d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 20 Jul 2012 10:07:26 +0400<br>
From: Ruslan Ermilov <<a href="mailto:ru@nginx.com">ru@nginx.com</a>><br>
To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
Subject: Re: a little bug in ngx_event_expire_timers<br>
Message-ID: <<a href="mailto:20120720060726.GA47268@lo0.su">20120720060726.GA47268@lo0.su</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
On Fri, Jul 20, 2012 at 12:11:51PM +0800, Joy zhou wrote:<br>
> hi everyone:<br>
> ??<br>
> ? I have found a little bug at method ngx_event_expire_timers? of? the<br>
> file "src/event/ngx_event_timer.c "<br>
> ??<br>
> ??<br>
> ???? 84???? for ( ;; ) {<br>
> ???? 85<br>
> ???? 86???????? ngx_mutex_lock(ngx_event_timer_mutex);<br>
> ???? 87<br>
> ???? 88???????? root = ngx_event_timer_rbtree.root;<br>
> ???? 89<br>
> ???? 90???????? if (root == sentinel) {<br>
> ???? 91???????????? return;<br>
> ???? 92???????? }<br>
> ????<br>
> ?????????????? [...]<br>
> ??????????? }<br>
> ????????????<br>
> ?? The above code should add?<br>
> "ngx_mutex_unlock(ngx_event_timer_mutex);" at 90 line,<br>
> ?? Because the ngx_event_timer_mutex has locked at begin , but returned<br>
> without unlock , is it right????????<br>
<br>
Only theoretically. Practically, ngx_mutex_lock() is a no-op in nginx.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 20 Jul 2012 08:22:00 +0000<br>
From: <a href="mailto:ru@nginx.com">ru@nginx.com</a><br>
To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
Subject: [nginx] svn commit: r4757 - trunk/src/http/modules<br>
Message-ID: <<a href="mailto:20120720082200.1F2B33FA05C@mail.nginx.com">20120720082200.1F2B33FA05C@mail.nginx.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Author: ru<br>
Date: 2012-07-20 08:21:59 +0000 (Fri, 20 Jul 2012)<br>
New Revision: 4757<br>
URL: <a href="http://trac.nginx.org/nginx/changeset/4757/nginx" target="_blank">http://trac.nginx.org/nginx/changeset/4757/nginx</a><br>
<br>
Log:<br>
Fixed debugging messages to account that limit_zone was renamed to limit_conn.<br>
<br>
<br>
Modified:<br>
trunk/src/http/modules/ngx_http_limit_conn_module.c<br>
<br>
Modified: trunk/src/http/modules/ngx_http_limit_conn_module.c<br>
===================================================================<br>
--- trunk/src/http/modules/ngx_http_limit_conn_module.c 2012-07-17 04:47:34 UTC (rev 4756)<br>
+++ trunk/src/http/modules/ngx_http_limit_conn_module.c 2012-07-20 08:21:59 UTC (rev 4757)<br>
@@ -238,7 +238,7 @@<br>
}<br>
<br>
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,<br>
- "limit zone: %08XD %d", node->key, lc->conn);<br>
+ "limit conn: %08XD %d", node->key, lc->conn);<br>
<br>
ngx_shmtx_unlock(&shpool->mutex);<br>
<br>
@@ -358,7 +358,7 @@<br>
ngx_shmtx_lock(&shpool->mutex);<br>
<br>
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, lccln->shm_zone->shm.log, 0,<br>
- "limit zone cleanup: %08XD %d", node->key, lc->conn);<br>
+ "limit conn cleanup: %08XD %d", node->key, lc->conn);<br>
<br>
lc->conn--;<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 20 Jul 2012 18:35:00 +0800<br>
From: Pass86 <<a href="mailto:pass86@gmail.com">pass86@gmail.com</a>><br>
To: "<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>" <<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>><br>
Subject: Re: a little bug in ngx_event_expire_timers<br>
Message-ID: <<a href="mailto:4B94046F-69DC-4AC3-8068-866D1BCFFFCF@gmail.com">4B94046F-69DC-4AC3-8068-866D1BCFFFCF@gmail.com</a>><br>
Content-Type: text/plain; charset=GB2312<br>
<br>
not using lock, why coding?<br>
<br>
???? iPhone<br>
<br>
? 2012-7-20?14:07?Ruslan Ermilov <<a href="mailto:ru@nginx.com">ru@nginx.com</a>> ???<br>
<br>
> On Fri, Jul 20, 2012 at 12:11:51PM +0800, Joy zhou wrote:<br>
>> hi everyone:<br>
>><br>
>> I have found a little bug at method ngx_event_expire_timers of the<br>
>> file "src/event/ngx_event_timer.c "<br>
>><br>
>><br>
>> 84 for ( ;; ) {<br>
>> 85<br>
>> 86 ngx_mutex_lock(ngx_event_timer_mutex);<br>
>> 87<br>
>> 88 root = ngx_event_timer_rbtree.root;<br>
>> 89<br>
>> 90 if (root == sentinel) {<br>
>> 91 return;<br>
>> 92 }<br>
>><br>
>> [...]<br>
>> }<br>
>><br>
>> The above code should add<br>
>> "ngx_mutex_unlock(ngx_event_timer_mutex);" at 90 line,<br>
>> Because the ngx_event_timer_mutex has locked at begin , but returned<br>
>> without unlock , is it right?<br>
><br>
> Only theoretically. Practically, ngx_mutex_lock() is a no-op in nginx.<br>
><br>
> _______________________________________________<br>
> nginx-devel mailing list<br>
> <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
<br>
End of nginx-devel Digest, Vol 33, Issue 20<br>
*******************************************<br>
</blockquote></div><br>