For validating all the m3u8 , below is the configuration
location ~.*.m3u8 {
secure_link $arg_token,$arg_expires;
secure_link_md5 "appsecret$uri$arg_expires";
if ($secure_link = "") {return 403;}
if ($secure_link = "0"){return 410;}
proxy_pass http://appserver:80;
}
What I need is the way
So I was looking at a upstream that has been flooded from multiple locations
and read that you can create what is called a blackhole within the upstream
what helps with the DDoS scenario.
Here Is My upstream config :
upstream web_rack {
server 127.0.0.1:9000 weight=1 fail_timeout=4;
server 127.0.
Update your web application for example (PHP) first then how ever many hours
later when all caches for your web application have cleared restart your
Nginx so it only accepts secure links.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,275668,275669#msg-275669
Trying to implement the secure link md5 token check .
Is there a way to verify secure link i.e. to generate token using secret
key and verify the token. If it matches it should allow the request .
And also to allow the request for token which doesn't matches so that while
rolling out the update
On 2017-07-26 13:36, Peter Booth wrote:
Vlad,
I'd suggest beginning by seeing whether or not this is real. If you
create a cron job that invokes netstat -ant every hour, then summarize
the connections and either view them manually or write them into an
influxdb and graph with grafana you will se
Vlad,
I'd suggest beginning by seeing whether or not this is real. If you create a
cron job that invokes netstat -ant every hour, then summarize the connections
and either view them manually or write them into an influxdb and graph with
grafana you will see whether or not the #tcp connections r
Hi Peter,
When we used this:
proxy_set_header If-Modified-Since $http_if_modified_since
...Nginx was caching 304 responses from the upstream when the client
requested If-Modified-Since (if it was the first request for that
object). Future requests by clients that didn't set the
If-Modified-
Hello list,
I'm graphing information from the nginx status page, and have noticed
something odd. The "Writing" connections are flat over time, not
correlated to the Active/Reading/Waiting connections and are steadily
increasing over time. Example for the past week:
https://pasteboard.co/GCH
Ryan,
Just to be pedantic, can you spell out exactly what you meant when you said
"and deliver future responses as 304 to clients even without the
If-Modified-Since header?"
What requests were triggering the 304 response?
Were you observing what a browser was seeing or were you using curl or wg
So this config seems to work:
proxy_cache_valid 200 3M;
proxy_cache_valid 304 0;
proxy_cache_valid 404 0;
proxy_cache_revalidate on;
proxy_ignore_headers Cache-Control Expires;
There is no need for:
proxy_set_header If-Modified-Since $http_if_modified_since;
On 26/07/2017 09:57, Ryan Barcla
Thanks for the reply Peter.
I've noticed something interesting and wondered if you could shed some
light on it.
Simply adding:
proxy_ignore_headers Cache-Control Expires;
Enables 304 responses from the origin server without setting:
proxy_set_header If-Modified-Since $http_if_modified_since
I can’t see an obvious issue, but I can say that there is no such thing as a
simple web server setup where caching is involved.
I have gray hairs that appeared after working with a high traffic retail
website that had seven levels of caching
(browser cache, CDN, hardware load balancer, nginx reve
The following config seems to work for the situation I discussed:
proxy_cache_valid 200 3M;
proxy_cache_valid 304 0;
proxy_cache_revalidate on;
proxy_set_header If-Modified-Since $http_if_modified_since;
proxy_ignore_headers Cache-Control Expires;
... can anybody see any problems with this conf
13 matches
Mail list logo
