On Fri, Aug 07, 2015 at 07:12:27AM -0400, tunist wrote:
Hi there,
so in the interest of balance, i just cut some parts out.
Yes, that’s usually a sensible thing to do. It just makes reading the
content a week later, a bit odd.
“Right now, it looks to me as if your config says that a request for
/file.mp4 will be handled in “location / {}”, which will just serve the
file /usr/local/nginx/html/file.mp4.”
why do you think that?
Given the request, and the location{} blocks in the config, “location
/{}”
looked like the best-match one to me.
That contains "try_files $uri " and then a fallback.
If you are not directly using nginx to serve the file from the
filesystem;
or using the nginx “mp4” directive to handle the file from the
filesystem;
it will probably be useful to explain what exactly you are doing, in
order to allow others reproduce the problem you are reporting.
there is a PHP application being served via this config that handles the
routing and serving of files, including mp4s.
To me, that says that it is not nginx that is sending the video, but
your php script.
So your php script is the place to look for any unexpected behaviour.
If you can start with “I make this request and I expect to get this
response”, then you will have a much easier time testing and seeing
where things fail.
On your test system, if you throw away all of the php stuff and just
serve
the file directly; or serve the file using the mp4 module does
everything
work as it should? If so, that points at where the problem probably is.
“Also, you seem to be testing with “curl -I -r”, and being surprised at
a HTTP 200 response. nginx returns HTTP 200 to HEAD requests for files.”
i have been testing with this format, as recommended here by a contributor
to video.js on github (mp4 video can be 'seeked' in fedora firefox, but not in win 7 firefox · Issue #2385 · videojs/video.js · GitHub):
That looks like it is a “please send me the whole file” request (Range:
bytes=0-), so I’d expect to get the whole file.
When I try a request like that against an nginx just serving the file, I
get back
HTTP/1.1 206 Partial Content
Content-Length: 4013
Content-Range: bytes 0-4012/4013
amongst the rest of the response.
i ran the curl command that you provided here and saw a continual stream of
unreadable characters in the terminal. i am not experienced with curl in the
terminal to the extent i can discern which would be the appropriate flags to
use here.
I suggest “-v” for verbose, “-H” with the one or two headers that you
actually care about, and then end the shell line with “2>&1 | cat -v |
less”, so that you can see a printable representation of the (binary)
body content.
All you really want to see are the headers, though.
i have removed the video that i posted as a test now. however, this one will
remain available:
https://www.ureka.org/file/play/7369/nasa%20mars%20anomalies%202010.mp4
I think that the problem is in the non-nginx complexity that has been
added.
Put that file in /usr/local/nginx/html/, and access is without using
php.
If that works, then you can choose whether to keep it that way, or to
reintroduce php.
thanks for assisting!
Good luck with it.
f
Francis D. [email protected]
