El 04/07/13 02:43, Yichun Zhang (agentzh) escribió: > 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 >>&by Eugaia - Nginx Development
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 <dakota@brokenpipe.ru> >>> wrote: >>> >>>> Hi, >>by Eugaia - Nginx Development
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 <dakota@brokenpipe.ru> wrote: >> >>> Hi, >>> >>> I am parsing a subrequest's body as it arrives. At some point I could >>> dby Eugaia - Nginx Development
Hi, El 05/12/12 11:52, Maxim Dounin escribió: > Please also see other point rightfully noted by Ruslan Khusnullin - > you can't use ngx_strcmp() in ngx_http_image_filter_get_value() as > it's used not only on null-terminated strings. If you check there's enough space to avoid buffer overruns, you could use the ngx_strcmp() macros to save on function calls. Marcus. ________________by Eugaia - Nginx Development
On 15/10/2011 14:09, agentzh wrote: > On Sat, Oct 15, 2011 at 6:43 PM, Eugaia<ngx.eugaia@gmail.com> wrote: >> If you were just wrapping around set_var, then no. It would only be able to >> handle non-reentrant code, just like setby. >> > Gathered so ;) I asked because I didn't want to miss any quick magic ;) Nope. WYSIWYG. :-) >> In order to have reentrant coby Eugaia - Nginx Mailing List - English
On 15/10/2011 13:33, agentzh wrote: > On Sat, Oct 15, 2011 at 6:16 PM, Eugaia<ngx.eugaia@gmail.com> wrote: >> On 15/10/2011 12:40, agentzh wrote: >>> Okay, I must say that ngx_rewrite's "last" won't affect rewrite_by_lua >>> because rewrite_by_lua is not part of that module (and there's no >>> known way to achieve that). >> You could achieby Eugaia - Nginx Mailing List - English
On 15/10/2011 12:57, Nginx User wrote: > Any thoughts on Marcus' points earlier on clearing the ctx in the core? > Seems to suggest that may cause problems elsewhere and that it is > better to be handled at the module level. > Seems logical as whether it was originally an oversight or not, > changing it now would break other stuff. I had a closer look at the code, and in fact cleariby Eugaia - Nginx Mailing List - English
On 15/10/2011 12:40, agentzh wrote: > Okay, I must say that ngx_rewrite's "last" won't affect rewrite_by_lua > because rewrite_by_lua is not part of that module (and there's no > known way to achieve that). You could achieve that now by creating a dummy variable, and instead of using a new handler for the rewrite by code, you wrap the code around the setby lua code. It wouldby Eugaia - Nginx Mailing List - English
On 13/10/2011 07:55, agentzh wrote: > Well, I still believe it is a bug in ngx_http_named_location function > in the nginx core. The thumb of rule is to avoid using named locations > like @proxy but use normal locations configured with the "internal" > directive. And we've been keeping doing this in our production apps. In some situations it's probably the desired effectby Eugaia - Nginx Mailing List - English
Hi Brian, On 19/08/2011 17:50, Akins, Brian wrote: > I'd like to be able to store some per-module, per-connection data. Like the > ctx in the requests. I was wondering if I should just patch nginx, or if > someone else had done something similar. Can I assume that in your case just storing the data in the c->data slot isn't going to work (easily/nicely)? e.g. typedef struct {by Eugaia - Nginx Development
Hi Igor, Congratulations on the new move. I hope it works out well for you. On 18/07/2011 17:14, Igor Sysoev wrote: > Our primary goals are improving support and communication for our users, > streamlining the development process, revamping the documentation, > integrating and speeding up pending bugfixes and patches, introducing > long-requested functionality and more. As well as tby Eugaia - Nginx Mailing List - English
Hi, > On Fri, 2011-05-27 at 15:38 -0400, Jack Desert wrote: > > Can I get a raise of hands who is interested in a more cohesive partnership between these two sites: > > nginx.org > wiki.nginx.org > > and what thoughts you have on the best way to do it? I think that it would be good to have a bot automatically check pages on nginx.org, which would add a notification tby Eugaia - Nginx Mailing List - English
Hi, On 04/05/2011 22:03, Akins, Brian wrote: > I wanted to use pcre inside a lua script using rex_pcre. However, I always > get the error: > > failed to get memory (pattern offset: 15) > > The snippet of code always works in a standalone script. > > Ideas? I just tried the supplied test suite for rex_pcre on the latest (as of a few days ago) trunk version of LuaJIT 2.0 oby Eugaia - Nginx Mailing List - English
Hi, On 13/04/2011 14:50, Anatoli Marinov wrote: > I succeed to remove the file after it is saved in tmp directory and > before to be moved in cache directory. > The patch is little bit ugly :) And wasteful too - it stores, then deletes the cache data. > ... > > Now from any filter when I have instance of request structure I can > set r->do_not_cache and the file will notby Eugaia - Nginx Development
Hi, On 22/02/2011 10:19, Elena Zwetkow wrote: > I will rethink my idea, but GridFS/MongoDB replication maintains > so nice instead of rsync copy jobs :) Given the popularity of MongoDB, I'm sure it won't be too long before an Nginx non-blocking module appears for it. This would probably happen quicker if the Mongo guys provided a async client C library. I would suggest contacting themby Eugaia - Nginx Mailing List - English
Hi, On 21/02/2011 18:56, Elena Zwetkow wrote: > Any ideas how to cache Files stored in GridFS? Perhaps Proxy_Cache can Store the files localy? Any Ideas are welcome. If you are at all concerned about performance, you might want to think about an alternative to using the gridfs module for Nginx. AFAIK it still uses the Mongo-provided C library, which is blocking, so you'll lose many of theby Eugaia - Nginx Mailing List - English
Hi, On 21/02/2011 01:32, Maxim Dounin wrote: > On Sun, Feb 20, 2011 at 10:33:25PM +0200, Eugaia wrote: >> Could you please elaborate on what you mean by the proxy cache being >> 'awful' for 'similar reasons'? > There is more than one issue with proxy cache, with more than one > leading to data corruption and/or protocol violation (and again > data corruption as a result).by Eugaia - Nginx Mailing List - English
Hi Maxim, On 19/02/2011 00:06, Maxim Dounin wrote: > ... > Sorry for being rude, but I've noticed the issue and commented > according to it's nature. I indeed consider anything which causes > data corruption to be awful (and this isn't the first data > corruption issue with forum, unfortunately). I also consider > nginx proxy cache to be awful for similar reasons - hope this wby Eugaia - Nginx Mailing List - English
Hi, On 15/02/2011 06:27, agentzh wrote: > For now, ngx_lua's "ngx.var.foo = xxx" assignment does not support > such special variables. This will change in a future release. This explains a lot. :-) By this do you mean it doesn't support variables with set handlers, or also changeable variables with different get handlers? Marcus. ______________________________________________by Eugaia - Nginx Mailing List - English
Hi, On 15/02/2011 00:22, António P. P. Almeida wrote: > On 14 Fev 2011 05h27 WET, agentzh@gmail.com wrote: .... >> Disclaimer: There may be other corner cases that I've missed here, >> and other more knowledgeable people can correct me wherever I'm >> wrong :) agentzh - well done on bringing this topic up - I'm sure doing so will help enlighten many who aren't so familiar wby Eugaia - Nginx Mailing List - English
Hi, .... On 13/02/2011 06:02, Richard Kearsley wrote: > > location /main { > > set $myvar ''; > > set $limit_rate 99; > .... > > set $limit_rate $myvar; > As well as the points agentzh made, there is also the case here that $limit_rate does a check on the values that it is set to, and it must be a valid size (internally this is done by having a set_handler attachedby Eugaia - Nginx Mailing List - English
Btw, /etc/mime.types does exist on my Debian 6 setup, it's just not an Nginx config file. Marcus. _______________________________________________ nginx mailing list nginx@nginx.org http://nginx.org/mailman/listinfo/nginxby Eugaia - Nginx Mailing List - English
Hi, On 13/02/2011 04:23, Ron Savage wrote: > Hi Folks > > I couldn't see a reference to this in the recent archives, and googling > didn't help. > > I've just installed Debian 6 on a new laptop, and compiled nginx 0.9.4 > with: > ./configure --with-http_ssl_module --with-http_gzip_static_module \ > --without-http_autoindex_module --without-http_browser_module > --wby Eugaia - Nginx Mailing List - English
Hi, On 10/02/2011 07:30, agentzh wrote: >> Is it also possible to pass an array of requests and get an array of >> responses, or otherwise send requests in parallel when you don't know in >> advance how many subrequests you want to issue? > Sure! For instance, > > -- construct the requests table > local reqs = {} > table.insert(reqs, { "/mysql&by Eugaia - Nginx Mailing List - English
Hi, On 19/01/2011 23:22, Dayo wrote: > I have actually already tried that with no success. Do you have multiple if blocks and have you read the if-is-evil stuff? http://wiki.nginx.org/IfIsEvil It sounds like a different block is being processed. Marcus. _______________________________________________ nginx mailing list nginx@nginx.org http://nginx.org/mailman/listinfo/nginxby Eugaia - Nginx Mailing List - English
On 18/01/2011 16:40, Igor Sysoev wrote: > On Tue, Jan 18, 2011 at 04:29:16PM +0200, Eugaia wrote: > >> Hi, >> >> On 18/01/2011 16:20, Igor Sysoev wrote: >>> 10485760000 is 0x271000000 in hex. On 32-bit platform it's truncated to >>> 0x71000000, i.e., 1895825408. Yes, it should be checked. >>> >> Also, would it not be better to use off64_t orby Eugaia - Nginx Mailing List - English
Hi, On 18/01/2011 16:20, Igor Sysoev wrote: > 10485760000 is 0x271000000 in hex. On 32-bit platform it's truncated to > 0x71000000, i.e., 1895825408. Yes, it should be checked. > Also, would it not be better to use off64_t or some other larger type for storing the max_size of the cache (or indeed for parsing off's in general)? I'm not sure about all Posix systems, but on Debian off_tby Eugaia - Nginx Mailing List - English
Hi, On 18/01/2011 06:30, agentzh wrote: > But chaoslawful > is currently working on the "cosocket" branch of ngx_lua that will > emulate a common set of Lua socket API that will give you totally > transparent non-blocking capability out of the box by means of a brand > new upstream layer atop the nginx event model and no nginx subrequest > overheads. Will this work onby Eugaia - Nginx Mailing List - English
Hi again, On 04/01/2011 12:47, Nuno Magalhães wrote: > ... > --add-module=/path/to/auto_lib \ > --add-module=/path/to/chunkin \ > --add-module=/path/to/headers_more By the way, auto_lib should always be the last additional module to be listed. You *may* fix the issues here if you put it last. Marcus. _______________________________________________ nginx mailing list nginx@nginx.oby Eugaia - Nginx Mailing List - English
Hi, On 04/01/2011 12:47, Nuno Magalhães wrote: > Hi again, > > The culprit was the upload module (v2.2.0), which makes sense since > that's when make fails (at the very end 'cos it was the last option). I'm pretty sure the culprit is probably the auto_lib module. It hasn't been thoroughly tested yet, and some (known) issues appeared in 0.9+ that have not been fixed yet (includingby Eugaia - Nginx Mailing List - English
![]() |
![]() |
![]() |
![]() |
![]() |