<div dir="ltr">Everything fine Maxim, thank you. Solved this by "return NGX_HTTP_FORBIDDEN", instead of "return <span style="font-family:arial,sans-serif;font-size:13px">ngx_http_output_filter</span>()".</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 3:09 PM,  <span dir="ltr"><<a href="mailto:nginx-devel-request@nginx.org" target="_blank">nginx-devel-request@nginx.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send nginx-devel mailing list submissions to<br>
        <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:nginx-devel-request@nginx.org">nginx-devel-request@nginx.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:nginx-devel-owner@nginx.org">nginx-devel-owner@nginx.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of nginx-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: nginx-devel Digest, Vol 58, Issue 34 (Donatas Abraitis)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 26 Aug 2014 15:09:44 +0300<br>
From: Donatas Abraitis <<a href="mailto:donatas.abraitis@gmail.com">donatas.abraitis@gmail.com</a>><br>
To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
Subject: Re: nginx-devel Digest, Vol 58, Issue 34<br>
Message-ID:<br>
        <CAPF+HwWp1ztj1VnfWTfSF5UwoHOq=<a href="mailto:BVDWCBA6mJFtN1JDcjzvA@mail.gmail.com">BVDWCBA6mJFtN1JDcjzvA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hey, Maxim,<br>
<br>
after trying to change to NGX_DONE or NGX_HTTP_FORBIDDEN in static<br>
ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf), I got this when doing<br>
nginx restart:<br>
<br>
nginx: configuration file /opt/nginx/etc/nginx.conf test failed<br>
<br>
Thank you.<br>
<br>
<br>
On Tue, Aug 26, 2014 at 3:00 PM, <<a href="mailto:nginx-devel-request@nginx.org">nginx-devel-request@nginx.org</a>> wrote:<br>
<br>
> Send nginx-devel mailing list submissions to<br>
>         <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
>         <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
> or, via email, send a message with subject or body 'help' to<br>
>         <a href="mailto:nginx-devel-request@nginx.org">nginx-devel-request@nginx.org</a><br>
><br>
> You can reach the person managing the list at<br>
>         <a href="mailto:nginx-devel-owner@nginx.org">nginx-devel-owner@nginx.org</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of nginx-devel digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
>    1. [nginx] Sub filter: fixed matching for a single character.<br>
>       (Valentin Bartenev)<br>
>    2. return 403 instead of next phase (Donatas Abraitis)<br>
>    3. Re: header value null termination? (Maxim Dounin)<br>
>    4. Re: return 403 instead of next phase (Maxim Dounin)<br>
>    5. Re: header value null termination? (Steven Hartland)<br>
>    6. Re: [PATCH 0 of 4 v3] Build-system: Cross-compilation support<br>
>       improvement (Samuel Martin)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Mon, 25 Aug 2014 12:09:28 +0000<br>
> From: Valentin Bartenev <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>
> To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> Subject: [nginx] Sub filter: fixed matching for a single character.<br>
> Message-ID:<br>
>         <<a href="mailto:hg.5322be87fc02.1408968568.6026610855610030274@dev.nginx.com">hg.5322be87fc02.1408968568.6026610855610030274@dev.nginx.com</a>><br>
> Content-Type: text/plain; charset="us-ascii"<br>
><br>
> details:   <a href="http://hg.nginx.org/nginx/rev/5322be87fc02" target="_blank">http://hg.nginx.org/nginx/rev/5322be87fc02</a><br>
> branches:<br>
> changeset: 5810:5322be87fc02<br>
> user:      Valentin Bartenev <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>><br>
> date:      Mon Aug 25 16:08:55 2014 +0400<br>
> description:<br>
> Sub filter: fixed matching for a single character.<br>
><br>
> diffstat:<br>
><br>
>  src/http/modules/ngx_http_sub_filter_module.c |  8 ++++++++<br>
>  1 files changed, 8 insertions(+), 0 deletions(-)<br>
><br>
> diffs (18 lines):<br>
><br>
> diff -r bb26f7ceaaf1 -r 5322be87fc02<br>
> src/http/modules/ngx_http_sub_filter_module.c<br>
> --- a/src/http/modules/ngx_http_sub_filter_module.c     Wed Aug 20<br>
> 13:13:27 2014 +0400<br>
> +++ b/src/http/modules/ngx_http_sub_filter_module.c     Mon Aug 25<br>
> 16:08:55 2014 +0400<br>
> @@ -546,6 +546,14 @@ ngx_http_sub_parse(ngx_http_request_t *r<br>
><br>
>              for ( ;; ) {<br>
>                  if (ch == match) {<br>
> +<br>
> +                    if (ctx->match.len == 1) {<br>
> +                        ctx->pos = p + 1;<br>
> +                        ctx->copy_end = p;<br>
> +<br>
> +                        return NGX_OK;<br>
> +                    }<br>
> +<br>
>                      copy_end = p;<br>
>                      ctx->looked.data[0] = *p;<br>
>                      looked = 1;<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Mon, 25 Aug 2014 17:07:12 +0300<br>
> From: Donatas Abraitis <<a href="mailto:donatas.abraitis@gmail.com">donatas.abraitis@gmail.com</a>><br>
> To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> Subject: return 403 instead of next phase<br>
> Message-ID:<br>
>         <CAPF+HwUmp0iLZKsGs4bDf4jw=<br>
> <a href="mailto:JY-EweOBKUnjK2DpgFJwdn8dw@mail.gmail.com">JY-EweOBKUnjK2DpgFJwdn8dw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Hey,<br>
><br>
> static ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf)<br>
> {<br>
>   ngx_http_handler_pt *h;<br>
>   ngx_http_core_main_conf_t *cscf;<br>
><br>
>   cscf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module);<br>
>   h = ngx_array_push(&cscf->phases[NGX_HTTP_ACCESS_PHASE].handlers);<br>
>   if(h == NULL)<br>
>     return NGX_ERROR;<br>
><br>
>   *h = ngx_http_hostprotect_handler;<br>
><br>
>   return NGX_OK;<br>
> }<br>
><br>
> static ngx_int_t ngx_http_hostprotect_handler(ngx_http_request_t *r)<br>
> {<br>
>     ...<br>
>     r->headers_out.status = NGX_HTTP_FORBIDDEN;<br>
>     r->headers_out.content_length_n = sizeof(err_msg);<br>
>     ngx_http_send_header(r);<br>
>     return ngx_http_output_filter(r, &out);<br>
> }<br>
><br>
> Everything looks fine, but backend (in this case Apache) still receives<br>
> requests. Any options to drop the request without allowing it to reach<br>
> backend?<br>
><br>
> --<br>
> Donatas<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<br>
> <a href="http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140825/a88a69b4/attachment-0001.html" target="_blank">http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140825/a88a69b4/attachment-0001.html</a><br>

> ><br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Mon, 25 Aug 2014 18:32:50 +0400<br>
> From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
> To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> Subject: Re: header value null termination?<br>
> Message-ID: <<a href="mailto:20140825143250.GF1849@mdounin.ru">20140825143250.GF1849@mdounin.ru</a>><br>
> Content-Type: text/plain; charset=us-ascii<br>
><br>
> Hello!<br>
><br>
> On Fri, Aug 22, 2014 at 12:30:22AM +0100, Steven Hartland wrote:<br>
><br>
> > I'm creating a module in which I needed to set some<br>
> > of the standard headers e.g. Content-Range and Range.<br>
> ><br>
> > Looking through the core source code the standard way<br>
> > to do this seems to be something like this:-<br>
> ><br>
> > r->headers_in.range->value.len =<br>
> >    ngx_sprintf(r->headers_in.range->value.data,<br>
> >        "bytes %O-%O/%O",<br>
> >        range->start, range->end - 1,<br>
> >        r->headers_out.content_length_n)<br>
> >        - r->headers_in.range->value.data;<br>
> ><br>
> > This appears to write a string to value.data which<br>
> > is not \0 terminated hence when interacting with<br>
> > functions such as ngx_http_range_parse unpredictable<br>
> > behaviour follows as it expects the range header to<br>
> > be null terminated.<br>
> ><br>
> > So the question is:-<br>
> ><br>
> > Should header values be null terminated or should<br>
> > functions such as ngx_http_range_parse be updated<br>
> > to deal with non-null terminated strings?<br>
><br>
> The answer is: no.<br>
><br>
> In general, strings in nginx are not null terminated, and there is<br>
> no need to null-terminated them.  In some cases though strings are<br>
> guaranteed to be null-terminated - notably, configuration<br>
> directive arguments are always null-terminated, as well as input<br>
> headers.  The ngx_http_range_parse() uses an input header from<br>
> r->headers_in, and it's guaranteed to be null-terminated.<br>
><br>
> The problem is in the "sample" code you've provided though: it<br>
> tries to modify input headers in r->headers_in.  This is wrong<br>
> thing to do.<br>
><br>
> --<br>
> Maxim Dounin<br>
> <a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Mon, 25 Aug 2014 20:09:35 +0400<br>
> From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
> To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> Subject: Re: return 403 instead of next phase<br>
> Message-ID: <<a href="mailto:20140825160935.GI1849@mdounin.ru">20140825160935.GI1849@mdounin.ru</a>><br>
> Content-Type: text/plain; charset=us-ascii<br>
><br>
> Hello!<br>
><br>
> On Mon, Aug 25, 2014 at 05:07:12PM +0300, Donatas Abraitis wrote:<br>
><br>
> > Hey,<br>
> ><br>
> > static ngx_int_t ngx_http_hostprotect_init(ngx_conf_t *cf)<br>
> > {<br>
> >   ngx_http_handler_pt *h;<br>
> >   ngx_http_core_main_conf_t *cscf;<br>
> ><br>
> >   cscf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module);<br>
> >   h = ngx_array_push(&cscf->phases[NGX_HTTP_ACCESS_PHASE].handlers);<br>
> >   if(h == NULL)<br>
> >     return NGX_ERROR;<br>
> ><br>
> >   *h = ngx_http_hostprotect_handler;<br>
> ><br>
> >   return NGX_OK;<br>
> > }<br>
> ><br>
> > static ngx_int_t ngx_http_hostprotect_handler(ngx_http_request_t *r)<br>
> > {<br>
> >     ...<br>
> >     r->headers_out.status = NGX_HTTP_FORBIDDEN;<br>
> >     r->headers_out.content_length_n = sizeof(err_msg);<br>
> >     ngx_http_send_header(r);<br>
> >     return ngx_http_output_filter(r, &out);<br>
> > }<br>
> ><br>
> > Everything looks fine, but backend (in this case Apache) still receives<br>
> > requests. Any options to drop the request without allowing it to reach<br>
> > backend?<br>
><br>
> In your code you return NGX_OK from the access phase handler, and<br>
> this means that access checks passed.  This probably not what you<br>
> mean to return.<br>
><br>
> You have to return NGX_HTTP_FORBIDDEN instead, without sending<br>
> anything back - nginx will send an error page for you (either<br>
> compiled in, or set with error_page directive).<br>
><br>
> --<br>
> Maxim Dounin<br>
> <a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Mon, 25 Aug 2014 19:56:13 +0100<br>
> From: "Steven Hartland" <<a href="mailto:steven.hartland@multiplay.co.uk">steven.hartland@multiplay.co.uk</a>><br>
> To: <<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>><br>
> Subject: Re: header value null termination?<br>
> Message-ID: <<a href="mailto:36576796BF8E4676B045066D8BF20D21@multiplay.co.uk">36576796BF8E4676B045066D8BF20D21@multiplay.co.uk</a>><br>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";<br>
>         reply-type=original<br>
><br>
><br>
> ----- Original Message -----<br>
> From: "Maxim Dounin" <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>><br>
> To: <<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>><br>
> Sent: Monday, August 25, 2014 3:32 PM<br>
> Subject: Re: header value null termination?<br>
><br>
><br>
> > Hello!<br>
> ><br>
> > On Fri, Aug 22, 2014 at 12:30:22AM +0100, Steven Hartland wrote:<br>
> ><br>
> >> I'm creating a module in which I needed to set some<br>
> >> of the standard headers e.g. Content-Range and Range.<br>
> >><br>
> >> Looking through the core source code the standard way<br>
> >> to do this seems to be something like this:-<br>
> >><br>
> >> r->headers_in.range->value.len =<br>
> >>    ngx_sprintf(r->headers_in.range->value.data,<br>
> >>        "bytes %O-%O/%O",<br>
> >>        range->start, range->end - 1,<br>
> >>        r->headers_out.content_length_n)<br>
> >>        - r->headers_in.range->value.data;<br>
> >><br>
> >> This appears to write a string to value.data which<br>
> >> is not \0 terminated hence when interacting with<br>
> >> functions such as ngx_http_range_parse unpredictable<br>
> >> behaviour follows as it expects the range header to<br>
> >> be null terminated.<br>
> >><br>
> >> So the question is:-<br>
> >><br>
> >> Should header values be null terminated or should<br>
> >> functions such as ngx_http_range_parse be updated<br>
> >> to deal with non-null terminated strings?<br>
> ><br>
> > The answer is: no.<br>
> ><br>
> > In general, strings in nginx are not null terminated, and there is<br>
> > no need to null-terminated them.  In some cases though strings are<br>
> > guaranteed to be null-terminated - notably, configuration<br>
> > directive arguments are always null-terminated, as well as input<br>
> > headers.  The ngx_http_range_parse() uses an input header from<br>
> > r->headers_in, and it's guaranteed to be null-terminated.<br>
> ><br>
> > The problem is in the "sample" code you've provided though: it<br>
> > tries to modify input headers in r->headers_in.  This is wrong<br>
> > thing to do.<br>
><br>
> Thanks for the confirming all input headers should be null<br>
> terminated, thats good to hear as thats what I did :)<br>
><br>
> The task I'm trying to achieve is quite a strange thing to be doing,<br>
> essentially I'm sending different headers to subrequests than the<br>
> original client sent.<br>
><br>
> I seems the only way to achieve this is to alter sr->headers_in<br>
> as in the sample; unless there's another way to do this?<br>
><br>
> As part of this project I've got a patch which adds the ability<br>
> to do range requests from 206 responses to<br>
> ngx_http_range_filter_module, is this something that you would<br>
> consider upstreaming?<br>
><br>
>     Regards<br>
>     Steve<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 6<br>
> Date: Tue, 26 Aug 2014 09:40:57 +0200<br>
> From: Samuel Martin <<a href="mailto:s.martin49@gmail.com">s.martin49@gmail.com</a>><br>
> To: <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> Subject: Re: [PATCH 0 of 4 v3] Build-system: Cross-compilation support<br>
>         improvement<br>
> Message-ID:<br>
>         <CAHXCMM+FRHB4oaH3c=<br>
> <a href="mailto:OKWiSQ-4oFJ%2BdO7Pqv%2BscQ4MVqw_2hPw@mail.gmail.com">OKWiSQ-4oFJ+dO7Pqv+scQ4MVqw_2hPw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=ISO-8859-1<br>
><br>
> Is this a "444 No Response" answer?<br>
><br>
> On Tue, Aug 12, 2014 at 4:03 PM, Samuel Martin <<a href="mailto:s.martin49@gmail.com">s.martin49@gmail.com</a>><br>
> wrote:<br>
> > ping?<br>
> ><br>
> > On Sat, Aug 2, 2014 at 1:14 AM, Samuel Martin <<a href="mailto:s.martin49@gmail.com">s.martin49@gmail.com</a>><br>
> wrote:<br>
> >> Hi all,<br>
> >><br>
> >><br>
> >> Here is the 3rd round of this short series improving nginx build-system<br>
> >> support for cross-compilation.<br>
> >><br>
> >> This series fixes a couple of issues found in the previous submission.<br>
> >> It still tries to be as less intrusive as possible, and intends to make<br>
> >> easier integration in cross-compilataion frameworks such as Buildroot<br>
> [1].<br>
> >><br>
> >> These patches include most of the changes needed for porperly supporting<br>
> >> the cross-compilation, except the sys_nerr guessing part [2], which<br>
> cannot<br>
> >> merged in nginx because it is too unix-oriented and based on fragile<br>
> >> assumptions<br>
> >><br>
> >><br>
> >> [1] <a href="http://buildroot.net/" target="_blank">http://buildroot.net/</a><br>
> >> [2]<br>
> <a href="https://github.com/tSed/buildroot/blob/nginx-integration/package/nginx/nginx-0005-auto-unix-make-sys_nerr-guessing-cross-friendly.patch" target="_blank">https://github.com/tSed/buildroot/blob/nginx-integration/package/nginx/nginx-0005-auto-unix-make-sys_nerr-guessing-cross-friendly.patch</a><br>

> >><br>
> >> Yours,<br>
> >> Samuel<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Samuel<br>
><br>
><br>
><br>
> --<br>
> Samuel<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> nginx-devel mailing list<br>
> <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
><br>
> End of nginx-devel Digest, Vol 58, Issue 34<br>
> *******************************************<br>
><br>
<br>
<br>
<br>
--<br>
Donatas<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140826/907e77bd/attachment.html" target="_blank">http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140826/907e77bd/attachment.html</a>><br>

<br>
------------------------------<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
<br>
End of nginx-devel Digest, Vol 58, Issue 35<br>
*******************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Donatas<br>
</div>