view tests/cgienv @ 37562:e5cd8d1a094d

lfs: special case the null:// usercache instead of treating it as a url The previous code worked on Windows, but not on Unix, and a pending patch's test failed. The url being used was something like "/tmp/.../client1/null://", courtesy of ui.configpath(). Looking at the doc comment, this seems like it's maybe not the right function to call (why should a relative cache path be expanded relative to the repo root or config file?), but largefiles has been using it since 8b8dd13295db (Oct 2011). It was introduced in 1b591f9b7fd2 (Jan 2011) without comment or callers. A grep over the whole history shows that only largefiles used it until lfs and infinitepush came along recently. It looks like if the `if not os.path.isabs(v) or "://" not in v` in configpath() is changed to an 'and', both Linux and Windows are happy. I'm guessing that "://" is to pick off URLs, so that seems reasonable. But I'm not sure why it isn't explicitly "file://", and I thought that "file://foo" is relative anyway. (At least, there are doctests for file:///tmp in util.url.) There is no mention of this setting in the help, but it is referenced on the wiki page for largefiles. (There's no mention that this is intended to be a URL, and the example uses an absolute path.) I don't want this blocking the rest of the lfs server discovery stuff. It was also wrong to allow a file:// URL here, but not in largefiles.
author Matt Harbison <matt_harbison@yahoo.com>
date Wed, 11 Apr 2018 17:29:55 -0400
parents aa3f726a2bdb
children
line wrap: on
line source

DOCUMENT_ROOT="/var/www/hg"; export DOCUMENT_ROOT
GATEWAY_INTERFACE="CGI/1.1"; export GATEWAY_INTERFACE
HTTP_ACCEPT="text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"; export HTTP_ACCEPT
HTTP_ACCEPT_CHARSET="ISO-8859-1,utf-8;q=0.7,*;q=0.7"; export HTTP_ACCEPT_CHARSET
HTTP_ACCEPT_ENCODING="gzip,deflate"; export HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE="en-us,en;q=0.5"; export HTTP_ACCEPT_LANGUAGE
HTTP_CACHE_CONTROL="max-age=0"; export HTTP_CACHE_CONTROL
HTTP_CONNECTION="keep-alive"; export HTTP_CONNECTION
HTTP_HOST="hg.omnifarious.org"; export HTTP_HOST
HTTP_KEEP_ALIVE="300"; export HTTP_KEEP_ALIVE
HTTP_USER_AGENT="Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.4) Gecko/20060608 Ubuntu/dapper-security Firefox/1.5.0.4"; export HTTP_USER_AGENT
PATH_INFO="/"; export PATH_INFO
PATH_TRANSLATED="/var/www/hg/index.html"; export PATH_TRANSLATED
QUERY_STRING=""; export QUERY_STRING
REMOTE_ADDR="127.0.0.2"; export REMOTE_ADDR
REMOTE_PORT="44703"; export REMOTE_PORT
REQUEST_METHOD="GET"; export REQUEST_METHOD
REQUEST_URI="/test/"; export REQUEST_URI
SCRIPT_FILENAME="/home/hopper/hg_public/test.cgi"; export SCRIPT_FILENAME
SCRIPT_NAME="/test"; export SCRIPT_NAME
SCRIPT_URI="http://hg.omnifarious.org/test/"; export SCRIPT_URI
SCRIPT_URL="/test/"; export SCRIPT_URL
SERVER_ADDR="127.0.0.1"; export SERVER_ADDR
SERVER_ADMIN="eric@localhost"; export SERVER_ADMIN
SERVER_NAME="hg.omnifarious.org"; export SERVER_NAME
SERVER_PORT="80"; export SERVER_PORT
SERVER_PROTOCOL="HTTP/1.1"; export SERVER_PROTOCOL
SERVER_SIGNATURE="<address>Apache/2.0.53 (Fedora) Server at hg.omnifarious.org Port 80</address>"; export SERVER_SIGNATURE
SERVER_SOFTWARE="Apache/2.0.53 (Fedora)"; export SERVER_SOFTWARE