Ocsp stapling

I have my nginx virtual host set to enable ocsp stapling but it doesn't actually do it. Ssllabs testing reports no. OpenSSL cli testing reports nothing. Nginx v1.8.0 Centos 6.7 64bit OpenSSL 1.0.1e I only have the ocsp config on one domain for testing. Any thoughts? Thanks. -- Fabe ___

Internal marked 503 error page returns default 404

Hi, I have the following configuration: server { location = /unavailable.html { internal; } try_files $uri =503; error_page 503 /unavailable.html; } My goal is to have all existing files with the exception of unavailable.html served with 200,

Re: preventing requests with unknown host names

On 8/21/2015 4:49 AM, navern wrote: > On 21.08.2015 10:30, Francis Daly wrote: >> On Thu, Aug 20, 2015 at 11:35:58PM -0700, Igal @ Lucee.org wrote: >>> On 8/20/2015 3:55 PM, Igal @ Lucee.org wrote: >> Hi there, >> >> I do not know the full answer to your question. >> >>> when I tried to add listen

auto/configure doesn't look for MINGW64 (on MSYS2)

Hi there, On MSYS2, with x64 compilers, the "auto/configure" file is not able to find the right environment. $ uname -s MINGW64_NT-10.0 But nginx is only looking for MINGW32. Regards, Billy Posted at Nginx Forum: http://forum.nginx.org/read.php?2,261172,261172#msg-261172

Re: CORS headers not being set for a 401 response from upstream.

To quote previous email from Maxim: "In javascript, the code should test the "status" property of the XMLHttpRequest object to find out if the request was successful or not" The problem here is that xhr.status === 0 if you don't have CORS headers present. If nginx doesn't allow you to add_heade

Re: large_client_header_buffers does not work in in server context

On Thursday 20 August 2015 15:10:16 Jason Thomas wrote: > Hello, > > large_client_header_buffers does not seem to work in server context, > however it works fine in http context. Documentation says it should work > for both [1] and looking at the application code it seems like it should > too [2].

Re: preventing requests with unknown host names

> You will need at least a proper ssl configuration in that server{} > block -- possibly setting it at http level. that makes sense. thanks again! Igal Sapir Lucee Core Developer Lucee.org On 8/21/2015 12:30 AM, Francis Daly wrote: > On Thu, Aug 20, 2015 at 11:35:58PM -0700,

Re: preventing requests with unknown host names

On 21.08.2015 10:30, Francis Daly wrote: On Thu, Aug 20, 2015 at 11:35:58PM -0700, Igal @ Lucee.org wrote: On 8/20/2015 3:55 PM, Igal @ Lucee.org wrote: Hi there, I do not know the full answer to your question. when I tried to add listen for port 443 it broke the https for requests with th

Re: preventing requests with unknown host names

On Thu, Aug 20, 2015 at 03:55:51PM -0700, Igal @ Lucee.org wrote: Hi there, > > For each "listen" directive with a unique ip:port, add one server{} > > block which contains "listen ip:port default_server; return 444;" > This seems to do the trick. > > I expected there to be a way to do all of th

Re: preventing requests with unknown host names

On Thu, Aug 20, 2015 at 11:35:58PM -0700, Igal @ Lucee.org wrote: > On 8/20/2015 3:55 PM, Igal @ Lucee.org wrote: Hi there, I do not know the full answer to your question. > when I tried to add listen for port 443 it broke the https for requests > with the valid hostname as well. > > ## disable