we have a shared macro/include used for letsencrypt verification, which proxies
requests to the `./well-known` directory onto an upstream provider.
the macro uses an old flag/semaphore based technique to toggle if the route is
enabled or not, so we can disable it when not needed. it works
On Dec 9, 2016, at 7:09 PM, Robert Paprocki wrote:
> Should be fairly easy to do with any command to write data over the wire
> (nc/netcat/echo into /dev/tcp):
Thanks for all this... I now mostly understand what was going on.
The *intent* of the nginx setup was do to the following, via 3
I got hit with a portscanner a few minutes ago, which caused an edge-case I
can't repeat.
the access log looks like this:
94.102.48.193 - [09/Dec/2016:22:15:03 +][_] 500 "GET / HTTP/1.0"
10299 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)" "-"
cookies="-"
the
On Dec 4, 2016, at 11:03 AM, Reinis Rozitis wrote:
> In case of https I don't even think it makes sense to provide any
> certificates (even self-signed).
> Without those the connection will/should be just terminated because of peer
> not providing any certificates and self-signed certs
On Nov 30, 2016, at 5:09 PM, steve wrote:
> Well, no as I've fixed this. However, if you have a probe for site x on
> https: and it doesn't exist, then the default https site for that IP address
> will be returned. Depending on configuration, it may still be attributed to
> the original
I'm not sure if this is a feature request or just an issue with our
deployment...
We host many domains, often partitioned across many configuration files
(ie: sites-enabled/domain1.conf,
sites-enabled/domain2.conf,
sites-enabled/domain3.conf,
)
An issue that has
On Nov 4, 2016, at 5:43 AM, mex wrote:
> we do a similar thing but keep a counter within nginx (lua_shared_dict FTW)
> and export this stuff via /badass - location.
>
> although its not realtime we have a delay of 5 sec which is enough for us
We have a somewhat similar setup under
I'm doing a quick audit on an nginx deployment and want to make sure something
is implemented correctly
We have a handful of domains that redirect http traffic to https.
we used to do this, which is very efficient:
sever {
listen 80:
server_name
On Sep 28, 2016, at 5:34 AM, jhernandez wrote:
> But we're not sure if 1.10.1 would support OpenSSL 1.0.2i. Has anyone tried
> this approach before ?
FYI, OpenSSL 1.1 and 1.02 branches had security fixes on 9/26 to their 9/22
releases
The current releases are:
1.0.2j
1.1.0b
On Jul 11, 2016, at 4:27 PM, Maxim Dounin wrote:
> No location information is added by nginx to error pages, and
> never was. You are probably using something with 3rd party
> patches. An obvious fix is to switch to using vanilla nginx
> instead, it can be downloaded here:
On Jul 11, 2016,
I have some servers where I use an old method of gating a path by using a file
check.
this allows staff to turn off certain locations during migrations/updates
without having root privileges (needed to restart nginx)
an issue I noticed– this method now (perhaps always) shows the name of the
On Mar 23, 2016, at 2:14 PM, Francis Daly wrote:
> Any directives that inherit do not need to be repeated.
>
> If it does not work for you, that's probably due to proxy_pass not
> inheriting.
Thanks - that's it -- `proxy_pass` does not inherit, but all the
`proxy_set_header` directives in
apologies for the simple question, but i could only find the opposite situation
in the list archives and I haven't had to reconfigure some of these routes in
years!
i have
# works
location /foo {
proxy_pass http://127.0.0.1:6543;
}
I want to lock down
On Mar 24, 2015, at 2:10 PM, Gena Makhomed wrote:
Probably you can do such tracking just looking at Referer request header
Long story short - we actually are doing that. This is just to get stats into
the HTTPS log analyzer, which is a different system and much easier for us to
deploy
On Mar 24, 2015, at 3:26 PM, Francis Daly wrote:
but the original if ($query_string) is probably simpler at
that point.
thanks for the help! it's great having a second set of eyes on this!
___
nginx mailing list
nginx@nginx.org
i need to redirecting from http to https, and append a source attribute for
tracking (we're trying to figure out how the wrong requests are coming in)
this seems to work:
if ($query_string){
return 301
I recently encountered an issue with a 1.5.7 branch on OSX. i did not check
1.5.8
The following code will set ALL css/js files as the default_type
include /usr/local/nginx/conf/mime.types;
default_type application/octet-stream;
The following code works as intended
we'd like to add onto the query string an identifier of the nginx server
something like:
return 301 https://$host$request_uri?source=server1 ;
the problem is that we can't figure out how to make this work correctly when
the url already contains query strings.
Example:
return
using the inet interface on supervisord was simple ( proxying to port 9001)
i wanted to turn that off, avoid tcp and just use the unix socket
after a bit of tinkering, this seems to work :
proxy_pass http://unix:///tmp/supervisord.sock:;
is this correct way to handle this ?
19 matches
Mail list logo
