On Jan 31, 2014, at 8:35 , Ruslan Ermilov wrote:
> Hi Piotr,
>
> On Thu, Jan 30, 2014 at 04:16:04PM -0800, Piotr Sikora wrote:
[ ... ]
> These seem questionable to me because the ioctl/fcntl calls are
> known to report back in errno, and they're not wrapped into ngx_foo()
> calls here.
>
> My
Hi Piotr,
On Thu, Jan 30, 2014 at 04:16:04PM -0800, Piotr Sikora wrote:
> # HG changeset patch
> # User Piotr Sikora
> # Date 1391126566 28800
> # Thu Jan 30 16:02:46 2014 -0800
> # Node ID fe4a9b7ca5985b0bde46fa78bd96de80e03d988b
> # Parent 2e40188f83ef5bf1ae5afe0dd445689049f46a5c
> Use ng
Hi Maxim,
On Fri, Jan 31, 2014 at 3:40 PM, Maxim Dounin wrote:
>
> A zero request time indicate that nginx never exhausted socket's
> output buffer while sending a response to a client, and hence was
> able to complete sending within a single event loop iteration.
> Time only refreshed before an
Hello!
On Fri, Jan 31, 2014 at 10:16:55AM +1300, Robert Coup wrote:
[...]
> > 2. Try to run
> > curl --limit-rate 100k
> > to be sure, that request time >> 1 ms.
> >
>
> Adding --limit-rate does give me a non-zero request time, but it seems to
> take quite a different code-path.
A zero request
Hello guys,
as Ruslan & Maxim noticed in the other thread, we're sometimes using
ngx_errno in places where we should be using ngx_socket_errno.
I might be overdoing it a little in src/os/unix/ngx_process.c, but
rest should be pretty obvious.
Best regards,
Piotr Sikora
# HG changeset patch
# Use
Hello,
slightly better patch attached.
Hopefully, now that ALPN (OpenSSL-1.0.2+ feature) is in, this can be
also committed :)
Best regards,
Piotr Sikora
# HG changeset patch
# User Piotr Sikora
# Date 1391123946 28800
# Thu Jan 30 15:19:06 2014 -0800
# Node ID 63c549cc2e817772979238f055b7
# HG changeset patch
# User Piotr Sikora
# Date 1391122701 28800
# Thu Jan 30 14:58:21 2014 -0800
# Node ID a2abc0e037c87626b30341014d8a35c36adf8f8f
# Parent 2e40188f83ef5bf1ae5afe0dd445689049f46a5c
Core: handle getsockopt(TCP_FASTOPEN) failures.
Linux returns EOPNOTSUPP for non-TCP sockets
Hi Anton,
Thanks for your efforts looking into this.
On Thu, Jan 30, 2014 at 11:09 PM, Anton Yuzhaninov wrote:
>
> 1. Do you have the timer_resolution directive in you config? Try to remove
> it for test.
>
No, just the default nginx.conf with changes as per my original email. If I
*add* "time
Hey Ruslan,
> This change breaks compilation with clang on systems
> where OpenSSL doesn't have ALPN support:
Good catch! Sorry for introducing this (even though it's clearly a
false positive)... I usually compile my ALPN & ecdh_auto patches
against both: OpenSSL-1.0.1 & OpenSSL-1.0.2, but I forg
details: http://hg.nginx.org/nginx/rev/2e40188f83ef
branches:
changeset: 5547:2e40188f83ef
user: Ruslan Ermilov
date: Thu Jan 30 19:13:12 2014 +0400
description:
Fixed a compile warning introduced by 01e2a5bcdd8f.
On systems with OpenSSL that has NPN support but lacks
ALPN support,
details: http://hg.nginx.org/nginx/rev/f385349d584b
branches:
changeset: 5546:f385349d584b
user: Ruslan Ermilov
date: Thu Jan 30 18:57:11 2014 +0400
description:
Proxy: fixed upstream search by proxy_pass with variables.
If "proxy_pass" is specified with variables, the resulting
hos
Hello!
On Thu, Jan 30, 2014 at 05:06:02PM +0400, Valentin V. Bartenev wrote:
> On Thursday 30 January 2014 16:45:18 Maxim Dounin wrote:
> > Hello!
> >
> > On Thu, Jan 30, 2014 at 01:55:23PM +0400, Ruslan Ermilov wrote:
> >
> > > On Wed, Jan 29, 2014 at 03:51:50PM +, Valentin Bartenev wrote:
On Thursday 30 January 2014 16:45:18 Maxim Dounin wrote:
> Hello!
>
> On Thu, Jan 30, 2014 at 01:55:23PM +0400, Ruslan Ermilov wrote:
>
> > On Wed, Jan 29, 2014 at 03:51:50PM +, Valentin Bartenev wrote:
> > > details: http://hg.nginx.org/nginx/rev/01e2a5bcdd8f
> > > branches:
> > > change
It hurts performance a tiny bit with a TLS handshake and 301 with extra
request, so for non spdy clients it would slow things down in terms of
initial page speed to make the entire site https . Also making the entire
site 301 to https might be bad for SEO (just guessing here, i might be
wrong: http
Hello!
On Thu, Jan 30, 2014 at 01:55:23PM +0400, Ruslan Ermilov wrote:
> On Wed, Jan 29, 2014 at 03:51:50PM +, Valentin Bartenev wrote:
> > details: http://hg.nginx.org/nginx/rev/01e2a5bcdd8f
> > branches:
> > changeset: 5545:01e2a5bcdd8f
> > user: Piotr Sikora
> > date: Tue Ja
On Thursday 30 January 2014 10:05:04 Ragnar Rova wrote:
> Sorry for the confusion regarding scheme value and actual connection method
> used. In my above example chrome is using a SSL connection to port 443 to
> fetch /foo/a.html, (verified using tcpdump), but the location field shows
> http://.
T
On 01/29/14 23:25, Robert Coup wrote:
I get a zero $request_time in the access log for gzipped+chunked transfer
requests if nothing else is running (ie. ngx_time_update() doesn't get called
for another request or something else). If I don't send Accept-Encoding with my
request I get the expected
On Wed, Jan 29, 2014 at 03:51:50PM +, Valentin Bartenev wrote:
> details: http://hg.nginx.org/nginx/rev/01e2a5bcdd8f
> branches:
> changeset: 5545:01e2a5bcdd8f
> user: Piotr Sikora
> date: Tue Jan 28 15:33:49 2014 -0800
> description:
> SSL: support ALPN (IETF's successor to NPN)
Sorry for the confusion regarding scheme value and actual connection method
used. In my above example chrome is using a SSL connection to port 443 to
fetch /foo/a.html, (verified using tcpdump), but the location field shows
http://.
Den 30 jan 2014 09:57 skrev "Igor Sysoev" :
> On Jan 30, 2014, at
On Jan 30, 2014, at 12:07 , Ragnar Rova wrote:
> Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy and
> setting the scheme: header to "http"
This is not bug, you can start Chrome with "--spdy=no-ssl" or probably
"--use-spdy=no-ssl" command line option and
then Chrome will
Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy and
setting the scheme: header to "http"
>From the users point of view it is not visible that a ssl connection was
used (no padlock icon etc), so I wanted a redirect to the https:// url
(mainly to show to the user that it is h
21 matches
Mail list logo
