<div dir="ltr">Hey, Maxim,<div><br></div><div>after trying to change to NGX_DONE or <span style="font-family:arial,sans-serif;font-size:13px">NGX_HTTP_FORBIDDEN in </span><span style="font-size:13px;font-family:arial,sans-serif">static ngx_int_t ngx_http_hostprotect_init(ngx_</span><span style="font-size:13px;font-family:arial,sans-serif">conf_t *cf), I got this when doing nginx restart:</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">nginx: configuration file /opt/nginx/etc/nginx.conf test failed</font><br></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">Thank you.</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 3:00 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. [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 src/http/modules/ngx_http_sub_filter_module.c<br>
--- a/src/http/modules/ngx_http_sub_filter_module.c Wed Aug 20 13:13:27 2014 +0400<br>
+++ b/src/http/modules/ngx_http_sub_filter_module.c Mon Aug 25 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=<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: <<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>
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=<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>> 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>> 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 [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 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] <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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Donatas<br>
</div>