Custom Query (2297 matches)

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.

Nginx configuration for the application:

location / {
	uwsgi_pass		unix:/var/tmp/x.sock;
	uwsgi_cache		palco_cache;
	uwsgi_cache_valid	404 1m;
	uwsgi_cache_valid	302 8h;
	uwsgi_cache_valid	200 204 7d;
	uwsgi_cache_key		$uri$is_args$args;
	uwsgi_cache_lock	on;
	uwsgi_cache_use_stale	error updating timeout invalid_header http_500;
	uwsgi_cache_purge	PURGE from all;
	include			uwsgi_params;
	add_header		X-Cache $upstream_cache_status;
	uwsgi_ignore_headers	"Expires" "Cache-Control";
}

The test application has a page that returns 200 and a content whatsoever, and another that returns 204 with the contents empty.

Below lay the answer to both.

204 HEADER:

HTTP/1.1 204 NO CONTENT
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 04 Jan 2013 21:19:51 GMT
Server: nginx
X-Cache: MISS

200 HEADER:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Fri, 04 Jan 2013 21:37:00 GMT
Server: nginx
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Cache: HIT

No matter the number of requests, a request that returns 204 is never cached.

The auto/make script sets some variables like $CC, $CFLAGS, and $LINK. It applies $CFLAGS to $CC which is correct. However, it sets $LINK to $CC without respecting $CFLAGS, which causes problems like

ld: fatal: file objs/src/core/nginx.o: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to objs/nginx
collect2: ld returned 1 exit status

when trying to build nginx 64bit on illumos.