On Nov 22, 2015, at 6:47 AM, j. van den hoff <veedeeh...@gmail.com> wrote: > > my (obviously > wrong/incomplete understanding so far is that `/wcontent' is an absolute > path relative to the repository root…
I think the problem is that you’re serving a collection of Fossils, instead of just one. I don’t use the CGI model, but with “fossil server /path/to/one.fossil” the URLs are of the form http://server.ip:port/wcontent. The difference with the “local” case is that “fossil ui” is only serving a single Fossil repo. So, bottom line, you need to either use relative URLs, or remove this confounding difference between the local and CGI cases, serving only one repo per Fossil server. You could still serve multiple Fossil repositories via your web server’s name-based virtual hosting feature, so that http://prj1.mycompany.private maps to prj1.fossil, and so on for prj2, etc. > hitting the > `/wcontent' link on the server GUI does not simply just not work with > error 404 or something like that but rather navigates to the home page of > another unrelated fossil cgi repository residing in the same directory on > the server. what's going on here? That sounds like a CGI-specific behavior. We use “fossil server /museum” (where /museum is where the Fossils live) here, and http://server:port/wcontent *does* give a 404. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
