nginx-devel Digest, Vol 58, Issue 35
Donatas Abraitis
donatas.abraitis at gmail.com
Tue Aug 26 17:41:51 UTC 2014
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, <nginx-devel-request at nginx.org> wrote:
> Send nginx-devel mailing list submissions to
> nginx-devel at nginx.org
>
> 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
> nginx-devel-request at nginx.org
>
> You can reach the person managing the list at
> nginx-devel-owner at nginx.org
>
> 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 <donatas.abraitis at gmail.com>
> To: nginx-devel at nginx.org
> Subject: Re: nginx-devel Digest, Vol 58, Issue 34
> Message-ID:
> <CAPF+HwWp1ztj1VnfWTfSF5UwoHOq=
> BVDWCBA6mJFtN1JDcjzvA at mail.gmail.com>
> 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, <nginx-devel-request at nginx.org> wrote:
>
> > Send nginx-devel mailing list submissions to
> > nginx-devel at nginx.org
> >
> > 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
> > nginx-devel-request at nginx.org
> >
> > You can reach the person managing the list at
> > nginx-devel-owner at nginx.org
> >
> > 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 <vbart at nginx.com>
> > To: nginx-devel at nginx.org
> > Subject: [nginx] Sub filter: fixed matching for a single character.
> > Message-ID:
> > <hg.5322be87fc02.1408968568.6026610855610030274 at dev.nginx.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > details: http://hg.nginx.org/nginx/rev/5322be87fc02
> > branches:
> > changeset: 5810:5322be87fc02
> > user: Valentin Bartenev <vbart at nginx.com>
> > 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 <donatas.abraitis at gmail.com>
> > To: nginx-devel at nginx.org
> > Subject: return 403 instead of next phase
> > Message-ID:
> > <CAPF+HwUmp0iLZKsGs4bDf4jw=
> > JY-EweOBKUnjK2DpgFJwdn8dw at mail.gmail.com>
> > 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 <mdounin at mdounin.ru>
> > To: nginx-devel at nginx.org
> > Subject: Re: header value null termination?
> > Message-ID: <20140825143250.GF1849 at mdounin.ru>
> > 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 <mdounin at mdounin.ru>
> > To: nginx-devel at nginx.org
> > Subject: Re: return 403 instead of next phase
> > Message-ID: <20140825160935.GI1849 at mdounin.ru>
> > 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" <steven.hartland at multiplay.co.uk>
> > To: <nginx-devel at nginx.org>
> > Subject: Re: header value null termination?
> > Message-ID: <36576796BF8E4676B045066D8BF20D21 at multiplay.co.uk>
> > Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> > reply-type=original
> >
> >
> > ----- Original Message -----
> > From: "Maxim Dounin" <mdounin at mdounin.ru>
> > To: <nginx-devel at 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. 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 <s.martin49 at gmail.com>
> > To: nginx-devel at nginx.org
> > Subject: Re: [PATCH 0 of 4 v3] Build-system: Cross-compilation support
> > improvement
> > Message-ID:
> > <CAHXCMM+FRHB4oaH3c=
> > OKWiSQ-4oFJ+dO7Pqv+scQ4MVqw_2hPw at mail.gmail.com>
> > 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 <s.martin49 at gmail.com>
> > wrote:
> > > ping?
> > >
> > > On Sat, Aug 2, 2014 at 1:14 AM, Samuel Martin <s.martin49 at gmail.com>
> > 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
> > nginx-devel at nginx.org
> > 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
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
> End of nginx-devel Digest, Vol 58, Issue 35
> *******************************************
>
--
Donatas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140826/380a48ff/attachment-0001.html>
More information about the nginx-devel
mailing list