Custom Query (2297 matches)

The proxy_store directive do not save the requested file if the file is not requested with a web browser.

This occurs when playing a HTTP Live Stream playlist with the VLC (2.0.3) Player. Reproducible with Mplayer (1.0_rc4_p20110322-r1). If mplayer request the file directly, nginx stores the file correctly. With Totem Media Player (2.32.0-r2) works.

If I try to get the files listed in the playlist with a Browser or cmdline client (Lynx,Firefox,Opera,Wget) nginx stores the file locally, as it should.

The client I am using is a gentoo system with: "Linux reipad 3.5.2-gentoo #6 SMP Thu Nov 1 08:29:16 CET 2012 x86_64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz GenuineIntel GNU/Linux"

#nginx.conf

location ~* ^{/hls/ondemand(/.*)\.ts {}

try_files $uri @ondemand;

} location ~* ^{/hls/m3u8(/.*)\.m3u8 {}

try_files $uri @ondemand;

}

location @ondemand {

internal; proxy_pass ​http://upstream_backend_storage; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /var/www;

}

#From the Log: $IP - - [16/Dec/2012:20:32:31 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_03_36.ts HTTP/1.1" 206 580732 "-" "VLC/2.0.3 LibVLC/2.0.3" $IP - - [16/Dec/2012:20:32:38 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_39_57.ts HTTP/1.0" 416 206 "-" "MPlayer SVN-r33094-4.5.3" $IP - - [16/Dec/2012:20:32:39 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_03_44.ts HTTP/1.1" 206 579228 "-" "VLC/2.0.3 LibVLC/2.0.3" $IP - - [16/Dec/2012:20:32:40 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_39_57.ts HTTP/1.0" 200 571520 "-" "MPlayer SVN-r33094-4.5.3" $IP - - [16/Dec/2012:20:32:40 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_39_57.ts HTTP/1.0" 200 571520 "-" "MPlayer SVN-r33094-4.5.3" $IP - - [16/Dec/2012:20:33:35 +0100] "GET /hls/ondemand/saal1_hq-2011.12.29-15_39_57.ts HTTP/1.1" 200 571520 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1"

This issue is reported regarding the web-site www.nginx.org (in particular the ​http://www.nginx.org/en/download.html page and the ​http://www.nginx.org/download/ directory). It's not related in any way to a particular version of nginx, so please dis-regard those entries which were required to contain valid values in order to submit this form.

For those of us who use scripts to determine whether we need to update (or in my case, I'm working on an automated build system for servers based on LFS); please add some way to automatically differentiate stable and release versions on your downloads page.

This could be achieved in any one of a number of ways, such as: a) putting -dev in the file names of development releases (which would also help if viewing the ​http://www.nginx.org/download/ folder directly); or b) by putting them in a different directory (/download/dev vs /download/releases); or c) on a different web-page (so download.html which can link to download-dev.html for development versions); or d) by having some parameter one could pass to the web-page to view only releases (such as download.html?releases); or e) by sym-linking the current release version such that it's obtainable either by looking at the content-disposition of the served page; or f) by having a page that does a 30x redirect to the correct file; or g) by having a numbering convention, such as "the second number being odd denotes test version - so 1.2.3 is release and 2.3.4 is test". By looking at your downloads folder I could not ascertain any such system, but if one exists please note it on download.html.

(Hopefully one is very simple? I can't be the only person who wants to do this :-).

Right now a script would have to parse HTML to determine which are release versions; which is difficult at best -- and a bit harder in this case as the download is in the middle of a massive unformatted block.

Cheers,

• S.

I'm using nginx in combination with TYPO3 CMS and would like to take advantage from gzip_static. TYPO3 does provide a way to pre-compress a couple of ressources.

However those ressources are written as - for example - file.css.gzip which isn't recognized by nginx's gzip_static module due to the fact that the module does look only for files having extensions like .gz.

Is there any chance to extend the gzip_static configuration directive to accept - besides its current options - as a second parameter a list of extensions? I could imagine something like gzip_static on "gz gzip gzip.css gzip.js"