On Sunday, 19 February 2017 18:28:30 GMT Ralph Corderoy wrote: > Have you found nginx's log files yet? It will give you a clue whether > the request for the MP3 is reaching it from the browser, and what it did > in turn.
I did originally, but it didn't tell me anything useful, so I didn't look again until just now; the entry was Error 404 - File not found. > I find I first get re-directed. > > $ curl -sSI > 'http://www.hadrian-way.co.uk/WMT/Guide/2)%20Gardens%20Area.mp3' HTTP/1.1 > 301 Moved Permanently > Content-Type: text/html; charset=iso-8859-1 > Connection: keep-alive > Keep-Alive: timeout=15 > Date: Sun, 19 Feb 2017 18:23:21 GMT > Server: Apache > Location: http://www.hadrian-way.co.uk/WMT/Guide/2)%20Gardens%20Area.MP3 > > And then told it's audio/mpeg. > > $ curl -sSI > 'http://www.hadrian-way.co.uk/WMT/Guide/2)%20Gardens%20Area.MP3' HTTP/1.1 > 200 OK > Content-Type: audio/mpeg > Content-Length: 3333768 > Connection: keep-alive > Keep-Alive: timeout=15 > Date: Sun, 19 Feb 2017 18:23:39 GMT > Server: Apache > Last-Modified: Sun, 19 Feb 2017 12:21:56 GMT > ETag: "32de88-548e1315f1ce6" > Accept-Ranges: bytes When I tried curl I suddenly got the clue; the filenames in my html are *.mp3 and the actual filenames are *.MP3. I changed the filenames on the server to match the ones in the code and it works! Presumably, Apache works some magic to ignore the case, whereas nginx doesn't. Thanks for all the clues (which I didn't always get). -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-03-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:[email protected] / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
