----- Original Message ----- From: "Maxim Dounin" <mdounin@mdounin.ru> To: <nginx-devel@nginx.org> Sent: Monday, August 25, 2014 3:32 PM Subject: Re: header value null termination? > Hello! > > On Fri, Aug 22, 2014 at 12:30:22AM +0100, Steven Hartland wrote: > >> I'm creating a module in which I needed to set some >> of the standard headers e.g. Cby steveh - Nginx Development
I'm creating a module in which I needed to set some of the standard headers e.g. Content-Range and Range. Looking through the core source code the standard way to do this seems to be something like this:- r->headers_in.range->value.len = ngx_sprintf(r->headers_in.range->value.data, "bytes %O-%O/%O", range->start, range->end - 1, r->headeby steveh - Nginx Development
Be good to see this in core, currently we use the 3rd party module to achieve this: http://wiki.nginx.org/HttpUpstreamRequestHashModule One question on the patch, you appear to have some commented out locking is this an oversight? Regards Steve ----- Original Message ----- From: "Jianjun Zheng" <codeeply@gmail.com> To: <nginx-devel@nginx.org> Sent: Thursday, May 0by steveh - Nginx Development
----- Original Message ----- From: "Maxim Dounin" <mdounin@mdounin.ru> To: <nginx-devel@nginx.org> Sent: Tuesday, November 19, 2013 4:52 PM Subject: Re: Patch: Prevent crit error being loggged on delete of non-existent file > Hello! > > On Tue, Nov 19, 2013 at 04:43:54PM -0000, Steven Hartland wrote: > >> Hi guys the attached patch prevents http file caby steveh - Nginx Development
Hi guys the attached patch prevents http file cache from logging a critical error when a file delete fails due to it not existing, which I'm sure was never the intention. N.B. Sorry if this appears as a duplicate, sent initially from the wrong email address. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd.by steveh - Nginx Development
My question is more, is there any reason why it can't support this? I can't think of any reason why this shouldn't be possible, its really only a block in my mind. You say there really no way to use include in upstream, but why is this? I know it can't currently but why? Its not a case of the vhosts using the same upstream but more multiple machines including blocks of hosts within to supporby steveh - Nginx Mailing List - English
We have a number of upstream blocks for different vhosts / processes but a number of them make use of the same backend nodes so I wanted to simply out upsteam declarations by using includes. On doing so we get the follow error:- nginx: "include" directive is not allowed here in /usr/local/etc/nginx/nginx.conf:61 Seems like include is not possible in an upstream block. I can't thinkby steveh - Nginx Mailing List - English
Ok I've figured this out but I'm not sure if its a bug or a "feature" the issue is that in stage #2 I was also setting: proxy_set_header X-Bytes-Sent $body_bytes_sent; This appears to cause $body_bytes_sent to be evaluated and "stored" so that subsequent uses of $body_bytes_sent don't call the method ngx_http_variable_body_bytes_sent to determine the amount of body bytes seby steveh - Nginx Mailing List - English
I'm trying to configure a post_action to submit details of downloads to our app but when I do the body_bytes_sent is always 0 even after a successful download. The flow we have is:- 1. external request 2. proxy pass to app for authorisation 3. app returns X-Accel-Redirect if authorised then process download 4. post_action to internal location 5. internal location proxy passes to app to regby steveh - Nginx Mailing List - English
Ok found the problem the send of the flv or mp4 is being triggered by an X-Accel-Redirect header who's content type is text/html. It seems this header is maintained by nginx when processing the flv send instead of setting up one from the configured mime.types. This is because the flv modules calls ngx_http_set_content_type to set this up which returns NGX_OK without making any changes if thereby steveh - Nginx Mailing List - English
For reference I'm pretty sure that its not connection setup / negotiation that is causing the load when enabled as the machines aren't dealing with that may new connections per second, so its an overhead for the entirety of the data send I believe. Ok so found something interesting, while mp4's are being sent with the correct header flv's aren't and hence are getting compressed: GET /streamiby steveh - Nginx Mailing List - English
Version info, both which exhibit this behaviour:- nginx version: nginx/0.8.53 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=wwwby steveh - Nginx Mailing List - English
Ok tested without gzip_static off, no change, commenting out the gzip off however and CPU usage starts to climb within seconds of a reload so its definitely gzip causing.by steveh - Nginx Mailing List - English
Ok this is weird I noticed tonight high CPU load on two out of three of our stream servers, which are serving mp4 and flv via the pseudo streaming modules. After investigating the differences between the two high CPU boxes and the one low CPU machine the only notable difference was that on the two high CPU boxes the config was including our standard gzip options:- gzip on; gzip_static on;by steveh - Nginx Mailing List - English
As far as I can tell passenger is reading / has read all the data and is sitting their waiting for more as it knows the total size. That's what alerted us to the issue in the first place as it complains about a corrupt post as its short. What would you expect to see when a write space event is triggered, another kevent line? If so any ideas what?by steveh - Nginx Mailing List - English
Sorry for the slow response, I expected to be auto subscribed to my own thread but wasnt. Anyway to answer some of the questions:- proxy_read_timeout 120 is whats triggering the timeout The OS is FreeBSD running 8-stable from just before Christmas so a recent 8.2-PRERELEASE, which should have any needed OS fixes in. FS is ZFS and while it does have some performance penalties (dual buffers aby steveh - Nginx Mailing List - English
In case its helpful there's some additional info on the passenger list here:- http://groups.google.com/group/phusion-passenger/t/51e2e1d124c16d5e?hl=enby steveh - Nginx Mailing List - English
I've been trying figure out a problem we are seeing in passenger module where by the full POST data isnt passed to the underlying application. After much digging I believe this may actually be a problem with the http_upstream / sendfile support in the core nginx code. The following log snippet shows a trace of this happening:- 2010/12/24 18:04:08 27169#0: *21 connected 2010/12/24 18:04:by steveh - Nginx Mailing List - English
Thanks for that, helps a lot. My initial test which made me think it was working, when it wasn't, seems to be due chrome frame some how caching the result of headers. So if you load a page once which triggers chrome mode due to the correct header in place, if you remove said header and reload it still loads in chrome frame. Will be down to how refresh works I expect. You live and learn :) Thby steveh - Nginx Mailing List - English
Hmm ok so it seems I was bitten by some unpredictable behaviour in gcf and this doesn't actually work. Setting just: add_header X-UA-Compatible "chrome=1"; in the server block or in an if within every location-if works but that's not ideal. Any ideas why add_header within a server-if doesn't work as expected?by steveh - Nginx Mailing List - English
I'm trying to add support for google chrome frame to our nginx config the simple way would be to include a fragment in each server block which looks something like: if ( $http_user_agent ~ chromeframe ) { add_header X-UA-Compatible "chrome=1"; } The problem is for some reason add_header isn't allowed in server-if blocks on location-if blocks. I can't see or thinby steveh - Nginx Mailing List - English