Re: duplicate Vary: Accept-Encoding header

On 20 January 2014 04:54, Makailol Charls wrote: > I use nginx/1.4.4 with gunzip = on and gzip_vary = on. This leads to a > duplicate Vary Header. [snip] > This issue is in standard ngx_http_header_filter_module so can anyone > suggest solution? Quick question: other than looking untidy, what's t

duplicate Vary: Accept-Encoding header

Hello, I use nginx/1.4.4 with gunzip = on and gzip_vary = on. This leads to a duplicate Vary Header. gzip_vary should do nothing if the header is already present: moki@mysrv:~$ curl -I http://192.168.1.196/home.html HTTP/1.1 200 OK Server: nginx/1.4.4 Date: Sun,

Re: cookie bomb - how to protect?

On Sun, Jan 19, 2014 at 1:42 PM, mex wrote: > hi coderman, > > icreasing the headerr_size is not a solution, since i look for a generic > solution to circumvent > the outcome of those malicious request. > > a possible way to handle this is a lighweight WAF-solution, > lua comes to my mind :) > ...

Re: cookie bomb - how to protect?

hi coderman, icreasing the headerr_size is not a solution, since i look for a generic solution to circumvent the outcome of those malicious request. a possible way to handle this is a lighweight WAF-solution, lua comes to my mind :) regards, mex p.s. we're working on a lighweight lua-b

Re: cookie bomb - how to protect?

On Sunday 19 January 2014 11:06:58 mex wrote: [..] > i checked it, and it works, i get the following error back: > > 400 Bad Request > > Request Header Or Cookie Too Large > > my question: is there a generic way to check the size of such headers like > cookies etc > and to cut them off, or shoul

Re: cookie bomb - how to protect?

On Sun, Jan 19, 2014 at 8:35 AM, coderman wrote: > > i'd love to know of more elegant ways to handle this, with header > specific handling - especially cookies, if possible... the less better way to change this is: http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_

Re: cookie bomb - how to protect?

On Sun, Jan 19, 2014 at 8:06 AM, mex wrote: > very interesting read: > http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html > > > my question: is there a generic way to check the size of such headers like > cookies etc and to cut them off, or should we live with such mal

cookie bomb - how to protect?

very interesting read: http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html from thze blogpost: "TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser will keep sending those cookies and servers will reject the re

Re: understanding proxy_buffering

¿One year or two?. I think that is a very optimist estimation. Extrapolating the information I get from a Windows program I execute in my laptop when I install software (it is a moment where you are writing files to the disk), I suppose you should expect a very much shorter life for your SSD disk.

Re: understanding proxy_buffering

Hadn't thought of that We could still use SAS 15K drives ,anyway even if the ssd thing works for a year or two I think the advantage will cover the cost Posted at Nginx Forum: http://forum.nginx.org/read.php?2,246586,246595#msg-246595 ___ nginx mailing

Re: nested location, proxy, alias and multiple "/" locations

On Sun, Jan 19, 2014 at 04:57:27AM -0500, sergiks wrote: Hi there, I'll describe what I think you want you want nginx to do. Please correct me where I've guessed wrongly. > There's a web root /var/www/site/ that responds to http://www.site.com > Then there's a Laravel (front controller php fram

Re: nested location, proxy, alias and multiple "/" locations

>> I'm not sure what you're trying do to. My bad, I'll explain it in other way. There's a web root /var/www/site/ that responds to http://www.site.com Then there's a Laravel (front controller php framework) installation in /var/www/Laravel1, and its web root folder is in /var/www/Laravel1/public

Re: understanding proxy_buffering

Hello One side question. Have you calculated a estimation of the expected life of a SSD disk when you are writing on it continously? I suppose that in such a situation it will die "quickly", due to the limited number of writes that the memory can support before getting damaged. Greetings. Oscar

understanding proxy_buffering

Hi I'm trying to setup a reverse proxy for some private downloads. Here is our setup: 3 Storage servers with High capacity but slow HDDs running nginx 1 loadbalancing server with SSD and high internet uplink. my file sizes are several hundred megabytes (500+ up to 2GB) running nginx downloaders are