On Wednesday 08 January 2014 00:10:16 Jonathan Matthews wrote:
> On 7 January 2014 23:57, Jonathan Matthews wrote:
> > The *only* context I can see this being even slightly useful is where
> > you are concerned about the unacceptably large size of the upstream
> > server's 404 page.
> >
> > If th
On 7 January 2014 23:57, Jonathan Matthews wrote:
> The *only* context I can see this being even slightly useful is where
> you are concerned about the unacceptably large size of the upstream
> server's 404 page.
>
> If this isn't your problem, I don't understand what you're trying to solve.
Eith
The *only* context I can see this being even slightly useful is where
you are concerned about the unacceptably large size of the upstream
server's 404 page.
If this isn't your problem, I don't understand what you're trying to solve.
___
nginx mailing li
I am using proxy_pass to a dynamic subdomain:
proxy_pass https://$remote_user.mydomain.io
Is it possible to have the proxy_pass check if the response of
https://$remote_user.mydomain.io is 404, if so, simply do:
return 404;
I.E. don't proxy, immediately return.
Posted at Nginx Forum:
1.0.1f against 1.5.9 mainline (today);
ecp_nistputil.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp521.obj : warning LNK4221: This object file does not define any
pr
On Tue, Jan 7, 2014 at 9:35 AM, coderman wrote:
>...
> in any case, end result: use 1.0.1f and be happy
and if concerned that your OS distribution or upstream OpenSSL lacks this fix,
confirm yourself via openssl-1.0.1f/crypto/engine/eng_rdrand.c in patched src
if you see !ENGINE_set_flags(e, E
On Mon, Jan 6, 2014 at 2:04 PM, Lukas Tribus wrote:
> Hi,
>
>
>> It does not look like 1.0.1f changed the default behavior of
>> ENGINE_rdrand (coderman's been following it).
>
> Yes it did, rdrand is no longer enabled by default. Here [1] is
> the backport in the OpenSSL_1_0_1-stable head [2].
>
Hi, have been trying to read the request body in my module, using the
information I have gotten from this forum and some blogs and basically came
up with the following functions
as can be seen in this post http://forum.nginx.org/read.php?11,245953. The
problem is that the request_body.bufs seem to
Create an account and just edit the wiki page.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,246089,246095#msg-246095
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
i want to submit my open souce nginx module to
http://wiki.nginx.org/3rdPartyModules, how can i do ?
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
On 06/01/14 21:02, Rob Stradling wrote:
On 06/01/14 20:40, Jeffrey Walton wrote:
There's also an Apple SecureTransport bug workaround. Apple's
SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
suites. It affects Mac OS X and could affect iOS. It might be prudent
to add SSL_OP_SAFA
11 matches
Mail list logo