Everything fine Maxim, thank you. Solved this by "return NGX_HTTP_FORBIDDEN", instead of "return ngx_http_output_filter()".
On Tue, Aug 26, 2014 at 3:09 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. Re: nginx-devel Digest, Vol 58, Issue 34 (Donatas Abraitis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 Aug 2014 15:09:44 +0300 > From: Donatas Abraitis <[email protected]> > To: [email protected] > Subject: Re: nginx-devel Digest, Vol 58, Issue 34 > Message-ID: > <CAPF+HwWp1ztj1VnfWTfSF5UwoHOq= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140826/907e77bd/attachment.html > > > > ------------------------------ > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > End of nginx-devel Digest, Vol 58, Issue 35 > ******************************************* > -- Donatas
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
