(cl == NULL) {
> +return NGX_HTTP_INTERNAL_SERVER_ERROR;
> +}
> +
> +b = cl->buf;
> +
> +ngx_memzero(b, sizeof(ngx_buf_t));
> +
> +b->in_file = 1;
> +b->file_last = rb->temp_file->file.offset;
> +b->file = &rb->temp_file->file;
> +
> +rb->bufs = cl;
> }
>
> post_handler(r);
Looks good and works fine (according to your test).
wbr, Valentin V. Bartenev
--
http://nginx.com/support.html
http://nginx.org/en/donation.html
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
name;
Mmodified;
Ssize;
}
map $arg_O $ord {
default asc;
Ddesc;
}
autoindex_sort $criteria $ord;
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
> hard to tell exactly from Chrome's Network tab.
>
Thank you for the report. I'm able to reproduce it.
> Turning off gzip fixes the issue. If there's a way to selectively
> disable gzip for SPDY requests, that would also be useful to know.
> hard to tell exactly from Chrome's Network tab.
>
> Turning off gzip fixes the issue. If there's a way to selectively
> disable gzip for SPDY requests, that would also be useful to know.
>
> Thanks,
Fixed in http://nginx.org/patches/spdy/patch.spdy-63_1.3.12.tx
nversion
> from 'off_t' to 'size_t', po
> ssible loss of data
> src/http/ngx_http_spdy.c(1642) : warning C4310: cast truncates constant
> value
> NMAKE : fatal error U1077: '"\Program Files\Microsoft Visual Studio
> 10.0\VC\bin\cl.EXE&
On Friday 08 March 2013 20:51:24 Valentin V. Bartenev wrote:
> On Friday 08 March 2013 14:16:36 三浦大佑 wrote:
> > Hi,
> > I have a problem about spdy support.
> >
> > I tried building Nginx with SPDY according to the page.
> > http://nginx.org/en/docs/howto_build
he patch looks good. I'll commit it as soon as Maxim acknowledges.
Thank you.
wbr, Valentin V. Bartenev
>
> This isn't much of an issue in patched code (only "ngx_fd_info()" test
> is actually reachable on Win32 and in worst case it might, but probably
> doesn&#x
On Monday 25 March 2013 18:41:28 Maxim Dounin wrote:
> Hello!
>
> On Mon, Mar 25, 2013 at 06:15:56PM +0400, Valentin V. Bartenev wrote:
> > On Thursday 21 March 2013 08:04:24 Piotr Sikora wrote:
> > > Hey guys,
> > > attached patch changes "if"
---
> File to patch:
>
Feel free to skip this patch of spdy patch series by using "-f" flag, since it
is for Windows systems.
Or please wait a bit for 1.3.15 with spdy inside.
wbr, Valentin V. Bartenev
--
http://nginx.org/en/donation.html
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
267 write(5, "84.201.173.232 - - [07/May/2013:"..., 213) =
> 213
> 9910 0.000300 close(14) = 0
>
> I tried to disable tcp_nopush using config file, but result is always the
> same.
>
> Could you please help me to resolve this issue?
Thank you for the rep
t;
Nice catch, thank you. I will push it after Maxim Dounin's acknowledgment.
wbr, Valentin V. Bartenev
> diff -r 886800caf360 -r c6434a863438 src/http/ngx_http_variables.c
> --- a/src/http/ngx_http_variables.c Mon Apr 29 18:58:58 2013 +0400
> +++ b/src/http/ngx_http_var
n(ctx->peer.connection);
> ngx_destroy_pool(ctx->pool);
> ngx_mail_session_internal_server_error(s);
> return;
The patch looks good for me. It would be nice if you provide it as
a mercurial changeset for pushing.
wbr, Valentin V. Bartenev
__
On Saturday 11 May 2013 21:30:39 Maxim Dounin wrote:
> Hello!
>
> On Wed, May 08, 2013 at 05:08:17AM +0400, Valentin V. Bartenev wrote:
> > On Thursday 02 May 2013 14:32:51 Piotr Sikora wrote:
> > > # HG changeset patch
> > > # User Piotr Sikora
> > &g
_conf_t *sscf;
> ngx_http_core_loc_conf_t *clcf;
> ngx_http_core_srv_conf_t *cscf;
> +ngx_int_t rc;
>
[...]
There's a style problem. Please, sort variable declarations in ascending order
of the length of their type name (or alphabetically
s.)
It's certainly not safe. In particular it will break spdy.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Friday 31 May 2013 08:52:41 Jim Radford wrote:
> On Fri, May 31, 2013 at 04:21:45AM +0400, Valentin V. Bartenev wrote:
> > On Friday 31 May 2013 02:24:50 Jim Radford wrote:
> > > This is a replacement to my previous patch which actaully includes the
> >
ilable.
>
> Avoid stripping the status text when proxying for compatibility with http.
>
[...]
The patch looks fine for me. I'll push it after Maxim Dounin's approval.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-dev
On Monday 10 June 2013 15:02:50 Valentin V. Bartenev wrote:
> On Saturday 08 June 2013 00:18:37 Jim Radford wrote:
> > # HG changeset patch
> > # User Jim Radford
> > # Date 1370636160 25200
> > # Node ID 18018b06ed3103c8a0e841e599
.]
No, it doesn't indicate that there is no data to send even in a short term.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Tuesday 25 June 2013 08:11:54 anshuk kumar wrote:
> Thanks for the reply.
>
> I have another question, was any state machine generators like ragel used
> to code this or this is completely hand written?
>
[..]
It's all written by hand. We don't use generators.
ere is a way to improve things a bit. We may postpone compression
to the latest phase (right before sending of queue), but it requires
more code and we have no ETA for this yet.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.
; }
>
> frame->next = *out;
> *out = frame;
> }
>
> Do you foresee any obvious drawback of such approach?
>
[..]
At first glance I don't. Indeed it can be a better strategy, particularly
since the SYN_STREAM frames are usually small.
Have you t
> are there any special limitations while including system headers?
> For sure this kind of behaviour is not nice and maybe it can be counted as
> bug (or at least be documented).
>
There is a commentary in the C++ example module (the only example that we have):
http://tr
I dig into nginx code yesterday, so I'm far from correctly understand where
> the real problem is, but this "patch" seems reasonable to me.
>
> Can someone with better nginx source code understanding, provide some
> feedback?
>
> And thanks for all your work!
Th
ther
of your patches next week.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
gt; static const ngx_str_t spdy = ngx_string(NGX_SPDY_NPN_NEGOTIATED);
>
> -SSL_get0_next_proto_negotiated(c->ssl->connection, &data, &len);
> +#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
> +SSL_get0_alpn_selected(c->ssl->connecti
rocess first checks the syntax validity, then tries to apply new
configuration, that is, to open log files and new listen sockets. If this
fails, it rolls back changes and continues to work with old configuration."
wbr, Valentin V. Bartenev
> On Mon, Dec 23, 2013 at 9:14 PM, Max
ROR) {
+ngx_http_spdy_finalize_connection(sc,
+c->error ? NGX_HTTP_CLIENT_CLOSED_REQUEST
+ : NGX_HTTP_INTERNAL_SERVER_ERROR);
+return;
+}
+}
+
sc->blocked = 0;
if (s
not the case in spdy, where headers and body comes in different frames
with known length.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
81bf72e
> fix typo
>
[..]
Thanks, committed with modified commit message.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
configuration changes
are required. Otherwise, please check the documentation:
http://nginx.org/en/docs/http/ngx_http_spdy_module.html
Thanks for testing.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.ngin
sending
data till the moment when we actually need the body,
(i.e. ngx_http_read_client_request_body() is called).
The last optimization can be useful for nginx, but it unnecessary
complicates implementation, what I would like to avoid at least
for a while.
wbr, Valentin V. Bartenev
On Tuesday 28 January 2014 02:37:12 Valentin V. Bartenev wrote:
[..]
> [..]
> > Also, it seems that receiving window size is hardcoded to 2GBs, which
> > makes flow control (which main point was to protect against single
> > stream, for example big POST upload, t
ely legal ways in SPDY to force a server to
do useless job, e.g. you can send hundreds of SYN_STREAMs followed by
RST_STREAMs with CANCEL status.
And the one you mentioned seems to me like a drop in the ocean.
Currently there is no way to protect from all of the possible cases
wi
> diff -r dea321e5c021 -r d848f32a9b67 src/http/ngx_http_spdy.h
> --- a/src/http/ngx_http_spdy.h Thu Oct 31 18:23:49 2013 +0400
> +++ b/src/http/ngx_http_spdy.h Thu Nov 14 12:58:27 2013 -0800
> @@ -17,7 +17,8 @@
>
> #define NGX_SPDY_VERSION 2
>
> -#ifdef TLSEXT_TYPE_next_proto_neg
> +#if (defined TLSEXT_TYPE_application_layer_protocol_negotiation
> \
> + || defined TLSEXT_TYPE_next_proto_neg)
> #define NGX_SPDY_NPN_ADVERTISE"\x06spdy/2"
> #define NGX_SPDY_NPN_NEGOTIATED "spdy/2"
> #endif
Same here. Let's just remove preprocessor condition at all.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
gt; SSL: support ALPN (IETF's successor to NPN).
[..]
Looks ok for me.
Maxim, do you approve this patch?
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
gt; SSL: support ALPN (IETF's successor to NPN).
>
> Signed-off-by: Piotr Sikora
>
[..]
Committed: http://hg.nginx.org/nginx/rev/01e2a5bcdd8f
Thank you.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.o
ser as https, you can use $scheme in a http to https
> redirect rule.
You can use it without this change. But the patch converts $scheme from
a configuration restricted variable into an untrusted one (which can contain
arbitrary value sent by client).
wbr, Valentin V. Bartenev
;>
> >>> I have
> >>>
> >>> server {
> >>>listen 1.2.3.4:80 <http://1.2.3.4/>;
> >>>
> >>>location ~ ^/(path1|path2)$ {
> >>> rewrite ^/(.*)$ https://mysite.com/$1 permanent;
&g
ndif
> >
> > +#else /* TLSEXT_TYPE_next_proto_neg */
> > +SSL_get0_next_proto_negotiated(c->ssl->connection, &data, &len);
> > +#endif
> > +
> > if (len == spdy.len && ngx_strncmp(data, spdy.data, spdy.len) ==
> > 0) {
> > ngx_http_spdy_init(c->read);
> > return;
>
> That's clearly a false positive warning, and I would rather add "data = NULL"
> under NGX_SUPPRESS_WARN as we usually do, something like this:
[..]
Of course you have the final word, but I like Ruslan's solution.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
02,7 +902,7 @@
> sc->length -= NGX_SPDY_SYN_STREAM_SIZE;
>
> sid = ngx_spdy_frame_parse_sid(pos);
> - prio = pos[8] >> 6;
> + prio = pos[8] >> 5;
>
> pos += NGX_SPDY_SYN_STREAM_SIZE;
>
Your email client broke the patch.
It's recommended to use mer
ugly in lowercase and most
> > of the variable and directive names in nginx is rather verbose...
> > "proxy_ssl_server_name" would also match "$ssl_server_name" (if that
> > ever gets merged...).
>
> Well, I don't think I care too much about the color. T
st.c Fri Mar 07 12:18:46 2014 +0800
> @@ -470,6 +470,7 @@
>
>
> rev->handler = ngx_http_process_request_line;
> ngx_http_process_request_line(rev);
> +ngx_http_run_posted_requests(c);
> }
>
Seems to me, this is a wrong patch, since ngx_http_wait_request_h
/ngx_http_spdy.c Wed Mar 26 10:55:33 2014 +0400
@@ -1496,7 +1496,6 @@ ngx_http_spdy_state_read_data(ngx_http_s
complete = 1;
} else {
-sc->length -= size;
complete = 0;
}
@@ -1539,6 +1538,8 @@ ngx_http_spdy_state_read_data(ngx_htt
y you described.
The "pos" pointer is adjusted as well right before
ngx_write_chain_to_temp_file()
is called.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Thursday 27 March 2014 09:02:57 Xiaochen Wang wrote:
> hi
>
>
> On Thu, Mar 27, 2014 at 1:01 AM, Valentin V. Bartenev
wrote:
>
> > On Wednesday 26 March 2014 12:30:11 Xiaochen Wang wrote:
> > > In our production, sometimes, the disk was full. In which case, th
On Wednesday 26 March 2014 15:46:05 Xiaochen Wang wrote:
> hi,
>
> On Wed, Mar 26, 2014 at 3:02 PM, Valentin V. Bartenev wrote:
>
> > On Wednesday 26 March 2014 12:30:11 Xiaochen Wang wrote:
> > > In our production, sometimes, the disk was full. In which case, the
&g
On Monday 14 April 2014 17:18:27 胡军伟 wrote:
> # SPDY patch
> # User Hu Junwei
> # Date 2014-04-14 11:27:39.304650193 +0800
> # Node ID
> # Parent
> SPDY: added stream-ID checking for SVN_STREAM.
>
> The stream-ID should be checked whether it increases monotonically.
>
[..]
While it would be goo
SO do i miss something important?
> nginx how to deal with this situation in read and write?
The question is: have you actually seen this problem in real life with a
typical TCP connection over network?
wbr, Valentin V. Bartenev
___
nginx-
(64k) received.
> Is this a bug or have i made something wrong in the config file?
> I’m really confusing and hope if someone could help me figure it out.
>
In the FastCGI protocol the data is transferred using "records". The maximum
size of one record is 64k. So you're
On Wednesday 18 June 2014 09:46:36 Jing Ye wrote:
> vbart,
>
> Thanks for the advice, but I’m afraid this is not the case. When i remove
> the 9902 upstream and curl again, it works properly and print 90833 at the
> end with only calling file_get_contents once.
>
> In addition, in the error.log w
bility with
> what nginx used to do for years. And it also looks like Apache
> does the same.
>
> Any other opinions?
>
I prefer to fix this instead of keeping it for another few years.
Uppercase digits also look more distinctly, since all other parts
of path are usually in lowercase.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
r->state = state;
> +
> return NGX_OK;
> }
>
Nice catch, thank you.
Maxim, do you approve this for push?
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Tuesday 08 July 2014 13:44:30 Valentin V. Bartenev wrote:
> On Tuesday 08 July 2014 02:29:21 Piotr Sikora wrote:
> > # HG changeset patch
> > # User Piotr Sikora
> > # Date 1404811064 25200
> > # Tue Jul 08 02:17:44 2014 -0700
> > # Node ID 0d4b169
> Is it a bug or ngx_conf_set_str_array_slot() use case is different?
>
[..]
You may just look at the directives that use this function.
For example: http://nginx.org/r/proxy_hide_header
Typical configuration can be:
proxy_hide_header X-Header-One;
proxy_hide_header X-Header-Tw
On Monday 01 September 2014 11:34:07 Nick Kew wrote:
[..]
> (That's against the 1.7.4 tarball: I didn't find anything looking
> like a dev repo).
[..]
http://hg.nginx.org/
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx
proved with
such number of style issues. You should consult with:
http://nginx.org/en/docs/contributing_changes.html#formatting_changes
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
What happens if you shutdown half of your cpus again, and try to reload nginx
under
high load?
As I understand right, with your patch it will close half of listen sockets,
and all
the connections that have been waiting to be accepted on these sockets will be
lost.
wbr, Valentin V. Bartenev
t = ev;
> ev->next = NULL;
>
> -#if (NGX_THREADS0)
> +#if (NGX_THREADS)
> ev->light = 1;
> #endif
>
No, thanks, that's not a typo.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Friday 26 September 2014 17:21:25 XiaoBing Jiang wrote:
> what is the macro meaning? I can't find any symbol in configure script.
>
It's meaning:
#if 0
ev->light = 1;
#endif
and the ngx_event_t structure has no the "light" member.
wbr, Valentin V.
lete it all.
wbr, Valentin V. Bartenev
> On Fri, Sep 26, 2014 at 6:55 PM, Valentin V. Bartenev wrote:
> > On Friday 26 September 2014 17:21:25 XiaoBing Jiang wrote:
> >> what is the macro meaning? I can't find any symbol in configure script.
> >>
> >
>
) and #if 0,
or just a shorter way to write #if (NGX_THREADS && 0).
For example, you can also find "#if (NGX_DEBUG0)".
Why actually do you care? That's a dead code anyway.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
9:51:56 +0900 (JST),
> Kouhei Sutou wrote:
>
[..]
http://mailman.nginx.org/pipermail/nginx-devel/2014-October/006054.html
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
http {
server {
listen 0.0.0.0:443 ssl;
}
server {
listen 127.0.0.1:443 ssl;
}
}
It works for me perfectly.
You should consult with the documentation: http://nginx.org/r/listen
And if it will not help, then please specify more de
On Tuesday 21 October 2014 04:16:01 Piotr Sikora wrote:
> # HG changeset patch
> # User Piotr Sikora
> # Date 1413890111 25200
> # Tue Oct 21 04:15:11 2014 -0700
> # Node ID fbc2eb84bd266b64644b00a6454c4f79f241af5a
> # Parent 973fded4f461f3a397779b3a1dc80881b1b34974
> SPDY: stop emitting emp
t++ = '\0';
> +}
>
> -last = ngx_cpymem(last, h[j].value.data, h[j].value.len);
> +last = ngx_cpymem(last, h[j].value.data, h[j].value.len);
> +}
>
>
parated
> non-empty values.
>
> Signed-off-by: Piotr Sikora
[..]
Thanks. Committed: http://hg.nginx.org/nginx/rev/87ada3ba1392
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
checked by it.
> If location @contents is a normal location such as /contents, a client
> request to /contents will not be passed app. It is not comfortable for me.
Why don't you use the Auth Request module?
http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
wbr, Val
, it may be the first
> architecture not supporting this syscall, but not the last one...
>
[..]
I believe the rtsig module in nginx is deprecated as well.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
was
> wondering if there was any reason to do it per ip.
>
http://mailman.nginx.org/pipermail/nginx/2014-February/042048.html
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
In fact, in my original version of patch the
whole code was in ngx_http_upstream_cache() but Maxim insisted on moving it
into a separate function just because the ngx_http_upstream_cache() is already
bloated.
wbr, Valentin V. Bartenev
___
nginx-devel maili
if (status == NGX_HTTP_NOT_MODIFIED) {
r->header_only = 1;
}
status = status - NGX_HTTP_MOVED_PERMANENTLY + NGX_HTTP_OFF_3XX;
status_line = &ngx_http_status_lines[status];
len += ngx_htt
{
> r->header_only = 1;
> ngx_str_null(&r->headers_out.content_type);
> r->headers_out.last_modified_time = -1;
> r->headers_out.last_modified = NULL;
> r->headers_out.content_length = NULL;
> r->header
pily
> connect via SPDY).
[..]
They use SPDY because it's advertised during TLS handshake using
NPN/ALPN TLS extensions.
The "Alternate-Protocol" header was introduced for cases when no
other mechanisms available (e.g. for plain HTTP conne
m binary protocol.
>
> Where can I find out some documentation or examples about it ?
The source code of mail, http and rtmp modules can be a good example.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http:/
;
> if (sid) {
> stream = ngx_http_spdy_get_stream_by_id(sc, sid);
>
Committed. Thanks!
http://hg.nginx.org/nginx/rev/199c0dd313ea
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
upport, and am pretty excited. Has the development already started? If
> yes, i would like to contribute. Please let me know. Thanks.
>
How would you like to contribute?
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.o
not familiar
with nginx internals.
> - understand source code written to support http/2, if any.
> - start with implementing small features, and fixing bugs.
There's a couple of open tickets about SPDY: http://trac.nginx.org
You can start by trying to fix them.
> You can start by trying to fix them.
> >
>
> actually there are no outstanding tickets abouty SPDY, or atleast i
> couldn't find them.
http://trac.nginx.org/nginx/ticket/714
http://trac.nginx.org/nginx/ticket/626
wbr, Valentin V. Bartenev
___
1
> 10170 GET /test HTTP/1.1
> 10170 GET /test HTTP/1.1
> .
> .
>
Thank you for the report.
It caused by a race condition between sendfile() task completion
and connection close notifications. If the latter comes first,
nginx logs that client prematurely closed connection.
Unfort
7;t a valid media type.
See RFC 7231: https://tools.ietf.org/html/rfc7231#section-3.1.1.1
Please fix your application.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
_str_t orig_addr_text;
> +#endif
> +
> ngx_str_t proxy_protocol_addr;
>
The realip module works on a per request basis, so storing this
information inside the connection structure looks wrong to me.
wbr, Valentin V. Bartenev
31f0b719204e582918
> geoip_check_cache option.
>
> Allow to enable GEOIP_CHECK_CACHE option in GeoIP lib. When enabled
> this lib checks for changes of DB every second and reload it if needed.
>
[..]
Why do you need this option? What problem are you trying to so
On Monday 20 July 2015 17:42:10 Novy, Ondrej wrote:
>
> 20. 7. 2015 v 18:44, Valentin V. Bartenev
> mailto:vb...@nginx.com>>:
> Why do you need this option? What problem are you trying to solve?
>
> I want to reload GeoIP database everytime it’s changed, without si
http2/
Thanks for testing.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
load"
> public-key-pins =
> "pin-sha256=\"aBBtZy0hiXFCr7RV/RqoJoTCMHEhrwtB6IfgSPCY2sA=\";
> pin-sha256=\"d6qzvu9zOKCb90Uez27xWltNsj0e1Md7GkYYkVoZwmm=\"; max-age=86400"
> x-frame-options = "DENY"
>
> I hope this is helpful.
>
We are unable to reproduce the problem with a simple configuration.
Could you provide your config?
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
On Friday 14 August 2015 13:52:06 dims wrote:
> Default ssl configuration:
> href="//www.domain.ru/css2/reset-min.css">
> When enable http2 link brokes
>
>
HTTP/2 does nothing with page content. You're probably using 3-rd party
modules like mod_pagespeed or s
/.+)$;
> try_files $uri =404;
> }
>
> When enable http2 variable HTTP_HOST absent in phpinfo
> If set fastcgi_param HTTP_HOST $http_host; in phpinfo():
> _SERVER["HTTP_HOST"]no value
[...]
Thanks for the report.
Please, try the new pat
n domain regardless of what Host/:authority
> header was provided) and I tried swapping them. Then whenever I hit
> https://joeshaw.org/ I was entered into a redirection loop. It seemed like
> it was not checking the :authority pseudo-header and always serving from
> the default_server.
e patch.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
in some level
below. As a result it didn't catch all the events.
Please also provide your configuration.
At the first glance it more looks like some client bandwidth limitation.
Could you describe your environment and how do you test it?
w
te: Mon Aug 17 17:42:02 2015 +0300
> > description:
> > Sub filter: support of multiple strings to replace.
> >
>
> Hello,
>
> Can you please provide an example of use.
>
> Thank you!
>
See an example in the module documentation:
http://ngin
On Tuesday 18 August 2015 12:44:06 Jim Popovitch wrote:
> On Tue, Aug 18, 2015 at 12:37 PM, Valentin V. Bartenev
> wrote:
> > On Tuesday 18 August 2015 12:08:12 Jim Popovitch wrote:
> >> On Mon, Aug 17, 2015 at 10:44 AM, Dmitry Volyntsev
> >> wrote:
> >>
ll the cookies are accessible in nginx itself via
> the `$cookie_NAME` variables.
Thank you for the report.
It should be fixed in the 3rd version of the patch:
http://nginx.org/patches/http2/
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx
On Monday 17 August 2015 16:24:20 Valentin V. Bartenev wrote:
> On Saturday 15 August 2015 08:23:45 Tatsuhiko Kubo wrote:
> > Hello.
> >
> > I have been trying patch.http2-v2_1.9.3.txt.
> > A response does not seem to be gzip-compressed even though gzip
> > direct
, or newly revisited, with HTTP/2, needing some similar
> workaround? Or has it been resolved, for SPDY &/or HTTP/2, and can be safely
> ignored?
>
There is no such issue with HTTP/2.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
mits recursion (not parallelism)
of subrequests, when one subrequest creates another subrequest and the
depth of this subsequent chain is limited.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
In fact, TLS compression has been disabled in NGINX since 1.1.6.
There's no reason to disable HTTP compression with HTTP/2.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
> It seems like over time an array that continues to grow (past the current
pool allocation) would leave memory claimed within the pool allocation that
it's no longer using or tracking
>
It's ok, since pools usually have relatively short lives.
wbr, Valentin V. Bartenev
_array.c is
> correct.
>
[..]
It's an intentional design decision. Moreover, there's no easy way
to return memory to pool. Even ngx_array_destroy() returns memory
only in very specific case, when the destruction is happened right
after the allocatio
1 - 100 of 223 matches
Mail list logo
