Hey, Maxim, after trying to change to NGX_DONE or NGX_HTTP_FORBIDDEN in static ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf), I got this when doing nginx restart:
nginx: configuration file /opt/nginx/etc/nginx.conf test failed Thank you. On Tue, Aug 26, 2014 at 3:00 PM, <[email protected]> wrote: > Send nginx-devel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nginx.org/mailman/listinfo/nginx-devel > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of nginx-devel digest..." > > > Today's Topics: > > 1. [nginx] Sub filter: fixed matching for a single character. > (Valentin Bartenev) > 2. return 403 instead of next phase (Donatas Abraitis) > 3. Re: header value null termination? (Maxim Dounin) > 4. Re: return 403 instead of next phase (Maxim Dounin) > 5. Re: header value null termination? (Steven Hartland) > 6. Re: [PATCH 0 of 4 v3] Build-system: Cross-compilation support > improvement (Samuel Martin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Aug 2014 12:09:28 +0000 > From: Valentin Bartenev <[email protected]> > To: [email protected] > Subject: [nginx] Sub filter: fixed matching for a single character. > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > details: http://hg.nginx.org/nginx/rev/5322be87fc02 > branches: > changeset: 5810:5322be87fc02 > user: Valentin Bartenev <[email protected]> > date: Mon Aug 25 16:08:55 2014 +0400 > description: > Sub filter: fixed matching for a single character. > > diffstat: > > src/http/modules/ngx_http_sub_filter_module.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diffs (18 lines): > > diff -r bb26f7ceaaf1 -r 5322be87fc02 > src/http/modules/ngx_http_sub_filter_module.c > --- a/src/http/modules/ngx_http_sub_filter_module.c Wed Aug 20 > 13:13:27 2014 +0400 > +++ b/src/http/modules/ngx_http_sub_filter_module.c Mon Aug 25 > 16:08:55 2014 +0400 > @@ -546,6 +546,14 @@ ngx_http_sub_parse(ngx_http_request_t *r > > for ( ;; ) { > if (ch == match) { > + > + if (ctx->match.len == 1) { > + ctx->pos = p + 1; > + ctx->copy_end = p; > + > + return NGX_OK; > + } > + > copy_end = p; > ctx->looked.data[0] = *p; > looked = 1; > > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Aug 2014 17:07:12 +0300 > From: Donatas Abraitis <[email protected]> > To: [email protected] > Subject: return 403 instead of next phase > Message-ID: > <CAPF+HwUmp0iLZKsGs4bDf4jw= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Hey, > > static ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf) > { > ngx_http_handler_pt *h; > ngx_http_core_main_conf_t *cscf; > > cscf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module); > h = ngx_array_push(&cscf->phases[NGX_HTTP_ACCESS_PHASE].handlers); > if(h == NULL) > return NGX_ERROR; > > *h = ngx_http_hostprotect_handler; > > return NGX_OK; > } > > static ngx_int_t ngx_http_hostprotect_handler(ngx_http_request_t *r) > { > ... > r->headers_out.status = NGX_HTTP_FORBIDDEN; > r->headers_out.content_length_n = sizeof(err_msg); > ngx_http_send_header(r); > return ngx_http_output_filter(r, &out); > } > > Everything looks fine, but backend (in this case Apache) still receives > requests. Any options to drop the request without allowing it to reach > backend? > > -- > Donatas > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140825/a88a69b4/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 25 Aug 2014 18:32:50 +0400 > From: Maxim Dounin <[email protected]> > To: [email protected] > Subject: Re: header value null termination? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > 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. 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->headers_out.content_length_n) > > - r->headers_in.range->value.data; > > > > This appears to write a string to value.data which > > is not \0 terminated hence when interacting with > > functions such as ngx_http_range_parse unpredictable > > behaviour follows as it expects the range header to > > be null terminated. > > > > So the question is:- > > > > Should header values be null terminated or should > > functions such as ngx_http_range_parse be updated > > to deal with non-null terminated strings? > > The answer is: no. > > In general, strings in nginx are not null terminated, and there is > no need to null-terminated them. In some cases though strings are > guaranteed to be null-terminated - notably, configuration > directive arguments are always null-terminated, as well as input > headers. The ngx_http_range_parse() uses an input header from > r->headers_in, and it's guaranteed to be null-terminated. > > The problem is in the "sample" code you've provided though: it > tries to modify input headers in r->headers_in. This is wrong > thing to do. > > -- > Maxim Dounin > http://nginx.org/ > > > > ------------------------------ > > Message: 4 > Date: Mon, 25 Aug 2014 20:09:35 +0400 > From: Maxim Dounin <[email protected]> > To: [email protected] > Subject: Re: return 403 instead of next phase > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Hello! > > On Mon, Aug 25, 2014 at 05:07:12PM +0300, Donatas Abraitis wrote: > > > Hey, > > > > static ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf) > > { > > ngx_http_handler_pt *h; > > ngx_http_core_main_conf_t *cscf; > > > > cscf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module); > > h = ngx_array_push(&cscf->phases[NGX_HTTP_ACCESS_PHASE].handlers); > > if(h == NULL) > > return NGX_ERROR; > > > > *h = ngx_http_hostprotect_handler; > > > > return NGX_OK; > > } > > > > static ngx_int_t ngx_http_hostprotect_handler(ngx_http_request_t *r) > > { > > ... > > r->headers_out.status = NGX_HTTP_FORBIDDEN; > > r->headers_out.content_length_n = sizeof(err_msg); > > ngx_http_send_header(r); > > return ngx_http_output_filter(r, &out); > > } > > > > Everything looks fine, but backend (in this case Apache) still receives > > requests. Any options to drop the request without allowing it to reach > > backend? > > In your code you return NGX_OK from the access phase handler, and > this means that access checks passed. This probably not what you > mean to return. > > You have to return NGX_HTTP_FORBIDDEN instead, without sending > anything back - nginx will send an error page for you (either > compiled in, or set with error_page directive). > > -- > Maxim Dounin > http://nginx.org/ > > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Aug 2014 19:56:13 +0100 > From: "Steven Hartland" <[email protected]> > To: <[email protected]> > Subject: Re: header value null termination? > Message-ID: <[email protected]> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > > ----- Original Message ----- > From: "Maxim Dounin" <[email protected]> > To: <[email protected]> > 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. 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->headers_out.content_length_n) > >> - r->headers_in.range->value.data; > >> > >> This appears to write a string to value.data which > >> is not \0 terminated hence when interacting with > >> functions such as ngx_http_range_parse unpredictable > >> behaviour follows as it expects the range header to > >> be null terminated. > >> > >> So the question is:- > >> > >> Should header values be null terminated or should > >> functions such as ngx_http_range_parse be updated > >> to deal with non-null terminated strings? > > > > The answer is: no. > > > > In general, strings in nginx are not null terminated, and there is > > no need to null-terminated them. In some cases though strings are > > guaranteed to be null-terminated - notably, configuration > > directive arguments are always null-terminated, as well as input > > headers. The ngx_http_range_parse() uses an input header from > > r->headers_in, and it's guaranteed to be null-terminated. > > > > The problem is in the "sample" code you've provided though: it > > tries to modify input headers in r->headers_in. This is wrong > > thing to do. > > Thanks for the confirming all input headers should be null > terminated, thats good to hear as thats what I did :) > > The task I'm trying to achieve is quite a strange thing to be doing, > essentially I'm sending different headers to subrequests than the > original client sent. > > I seems the only way to achieve this is to alter sr->headers_in > as in the sample; unless there's another way to do this? > > As part of this project I've got a patch which adds the ability > to do range requests from 206 responses to > ngx_http_range_filter_module, is this something that you would > consider upstreaming? > > Regards > Steve > > > > ------------------------------ > > Message: 6 > Date: Tue, 26 Aug 2014 09:40:57 +0200 > From: Samuel Martin <[email protected]> > To: [email protected] > Subject: Re: [PATCH 0 of 4 v3] Build-system: Cross-compilation support > improvement > Message-ID: > <CAHXCMM+FRHB4oaH3c= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Is this a "444 No Response" answer? > > On Tue, Aug 12, 2014 at 4:03 PM, Samuel Martin <[email protected]> > wrote: > > ping? > > > > On Sat, Aug 2, 2014 at 1:14 AM, Samuel Martin <[email protected]> > wrote: > >> Hi all, > >> > >> > >> Here is the 3rd round of this short series improving nginx build-system > >> support for cross-compilation. > >> > >> This series fixes a couple of issues found in the previous submission. > >> It still tries to be as less intrusive as possible, and intends to make > >> easier integration in cross-compilataion frameworks such as Buildroot > [1]. > >> > >> These patches include most of the changes needed for porperly supporting > >> the cross-compilation, except the sys_nerr guessing part [2], which > cannot > >> merged in nginx because it is too unix-oriented and based on fragile > >> assumptions > >> > >> > >> [1] http://buildroot.net/ > >> [2] > https://github.com/tSed/buildroot/blob/nginx-integration/package/nginx/nginx-0005-auto-unix-make-sys_nerr-guessing-cross-friendly.patch > >> > >> Yours, > >> Samuel > > > > > > > > -- > > Samuel > > > > -- > Samuel > > > > ------------------------------ > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > End of nginx-devel Digest, Vol 58, Issue 34 > ******************************************* > -- Donatas
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
