aha! thanks so much. the problem was that the files in 'sites-enabled' were not links, they had somehow been made into actual copies of the files in sites-available - so when i edited the files in 'sites-available' the changes were not being reflected in the 'sites-enabled' versions. i have no idea how that occurred, but at least now it is fixed. :)by tunist - Nginx Mailing List - English
thanks for responding here. yes, i have reloaded the configuration using reload. the configtest results in: nginx: could not build optimal types_hash, you should increase either types_hash_max_size: 2048 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is suby tunist - Nginx Mailing List - English
i have just setup a new server that runs nginx 1.10.2 and have now enabled SSL on port 443. i have used a configuration that is based on the one i am successfully running on a different server and yet nginx is not listening to port 443 using this configuration. i have changed many options in the nginx.conf and site config files but no matter what i do i am unable to reach my site via SSL and whenby tunist - Nginx Mailing List - English
i did explore that possibility for several days, but did not achieve success. part of the problem is that the videos have dynamic privacy settings applied to them and so PHP is used to decide which videos the present user can view and which ones they cannot view. i looked at using various directives in nginx to bypass this but never found a way to do it.by tunist - Nginx Mailing List - English
thanks again for assisting. i have resolved this now since i realised that the php file i use to stream the files did not support partial content ;) i thought that nginx had some kind of built in 'magical' support for that which meant that my application didn't need to handle it. however, that is not the case and once i added in a PHP class to handle the partial requests, the files now seek correby tunist - Nginx Mailing List - English
aha! yes, the cause of the problem was the lack of range handling in the PHP page i am using for streaming the files. i forgot that that is a requirement of the process! i have added the videostream class to the page and so far the streaming is working well in my tests :)by tunist - Nginx Mailing List - English
oh, so it seems likely that i need to add extra logic into the PHP page that handles the video stream to support range requests - as detailed here: http://codesamplez.com/programming/php-html5-video-streaming-tutorialby tunist - Nginx Mailing List - English
oh, so it seems likely that i need to add extra logic into the PHP page that handles the video stream to support range requests - as detailed here: http://codesamplez.com/programming/php-html5-video-streaming-tutorialby tunist - Nginx Mailing List - English
yes, i removed some of the original question since it was shown to not be relevant to the issue. i appreciate that maybe it would be best to write 'EDIT:' when i edit there, but then the question might become huge.. so in the interest of balance, i just cut some parts out. "Right now, it looks to me as if your config says that a request for /file.mp4 will be handled in "location / {}by tunist - Nginx Mailing List - English
i have now updated the serverfault question to include the nginx config files.by tunist - Nginx Mailing List - English
i mentioned the possibility of a bug since i have already exhausted all options presented to me via numerous channels of research and support. i will post my server/site's full config to serverfault shorly.by tunist - Nginx Mailing List - English
i have now created question on this topic on serverfault and on stackexchange's video site - but have not found the solution to the problem. i have looked into all the answers i have received so far and none have made any difference to the fact that my server is not reliably serving video. all my MP4s are now processed to relocate the moov atom. anyone got any additional thoughts? is there a githby tunist - Nginx Mailing List - English
i thought i had solved this by adding the header for accept-ranges - since when i did that i could then seek in firefox on windows 7. however, after testing further i found that the results are inconsistent and ultimately it is still somewhat broken. i have added more details to this to a new question i have asked at serverfault: http://serverfault.com/questions/710304/why-is-partial-content-not-by tunist - Nginx Mailing List - English
oh, so the solution here was to add: add_header Accept-Ranges bytes; to the site's config file.by tunist - Nginx Mailing List - English
greetings! i am seeing an unexplained malfunction here with nginx when serving videos. flv and mp4 files have different symptoms. mp4 streams correctly when i view the file in firefox 39 in fedora 22, but in windows 7 (firefox 39) the file cannot be 'seeked' and must be played linearly. after speaking with the coders of video.js (the player i use), it was determined that nginx is not returningby tunist - Nginx Mailing List - English
Konstantin Pavlov Wrote: ------------------------------------------------------- > Nginx source code does not contain a service file for systemd. You're > free to re-use the one shipped in the official packages available on > http://nginx.org/en/linux_packages.html#mainline. > > Also, it might be worth rebuilding an official source rpm package - > the > fedora sysby tunist - Nginx Mailing List - English
i just built the latest mainline nginx from source on fedora 21 (64bit) and when i run: service nginx start i see: Redirecting to /bin/systemctl start nginx.service Failed to start nginx.service: Unit nginx.service failed to load: No such file or directory. i've searched around online and so far found no-one else reporting the same issue. i think i have fixed this before on another inby tunist - Nginx Mailing List - English
having difficulty to serve simple video files here (for playback in a browser via video-js or other player). even without the video player there are problems. i have tested access to the video file both when the file is served from within the php framework i am using (elgg.org) and also directly from a public location on the webserver. in some circumstances the file 'might' play and in others i sby tunist - Nginx Mailing List - English
ok great, thanks for assistingby tunist - Nginx Mailing List - English
i was having a lot of trouble with 302 errors initially and then later on was having slow TLS performance.. i had difficulty finding the right combination of buffer settings to get the site to run reliably and quickly. if i recall correctly, that was a field that i changed while i was in the process of stabilising the site. possibly there was no need to change that one and i just left the changeby tunist - Nginx Mailing List - English
ok, so i opened the log using glogg and have pasted a relevant sequence into pastebin here: http://pastebin.com/wTQs6ALb any tips welcome, thanksby tunist - Nginx Mailing List - English
oh, so the log file is 3.5GB in size and even though the server has enough RAM to handle it, the log viewer crashes and gedit gets stuck too.by tunist - Nginx Mailing List - English
enabling debug on the site in question generated vast amounts of log data and i think either some type of limit was reached or a bug caused the logging to fail. i was unable to open the logviewer for the site's error log after the first few minutes and eventually the interface crashed while attempting to open the log. now i have disabled debug again and can open the log. the logging stopped shortby tunist - Nginx Mailing List - English
"There's no way to find out what caused the error only by looking to standard error message. You should provide the debug log at least." - ok, thanks - i will post what i can find once the next error occurs. i upgraded to 1.7.7 and there have been 2 of these errors since then, though debug was not enabled at that point.by tunist - Nginx Mailing List - English
ok, i have upgraded.. will see how that goes.by tunist - Nginx Mailing List - English
thanks, looks like the same error message is buried in that change / code, yes - though i am no closer to discerning the original cause of the error being triggered, since i am not familiar with the nginx sourecode at this point. any tips are welcomed!by tunist - Nginx Mailing List - English
i am seeing many error log messages relating to SPDY on an HTTPS only website here. this appears to also be triggering (or at least related to) database timing problems, which is causing dbase failures. the error log contains mostly these: "inflate() failed: -5 while processing SPDY" anyone know what's occuring here? i think i already asked a similar question on a forum and someby tunist - Nginx Mailing List - English
thanks, yes - i just thought to do that before i read your reply. the test says my server is not vulnerable to the attack - so the bugfixes appear to have been integrated into the latest fedora version of openssl, even though running the openssl version command does not show this to be the case. so i just put up with the regular error log entries for inflate? mex Wrote: --------------------by tunist - Nginx Mailing List - English
fedora 20 - latest version of openssl = 1:openssl-1.0.1e-40.fc20.x86_64 though when i run openssl version, i see: OpenSSL 1.0.1e-fips 11 Feb 2013 not sure why..!? mex Wrote: ------------------------------------------------------- > CCS-scan probably, see > https://www.mare-system.de/guide-to-nginx-ssl-spdy-hsts/#ccs-early-cha > ngecipherspec-attack) > > what openssby tunist - Nginx Mailing List - English
oh, and another: *188425 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: xx.xx.xx.xx.xx, server: 0.0.0.0:443 is this maybe a result of hackers attempting to break into the server?by tunist - Nginx Mailing List - English