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 (https://github.com/videojs/video.js/issues/2385):

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 Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx