Re: [fossil-users] delete a branch
There is something unsatisfying about the mistake solution, at least that is my feeling. Conceptually, there is a difference between not deleting history (which I think is a very valuable asset in fossil) and always showing full history, rubbing mistakes in your face, especially when still learning fossil. Perhaps it is bloat, but would it be useful if branches with the tag 'mistake' or perhaps 'hidden' were not shown on the default timeline in the web interface, and having an option for showing the full timeline? It would be a bit like the full file view and the current file view when showing files. Paul On 30 Sep 2011, at 22:30 , Richard Hipp wrote: On Fri, Sep 30, 2011 at 4:14 PM, Tomek Kott tkott.s...@gmail.com wrote: nope*. What many people do, including the SQLite Fossil repos, is simply rename the branch as mistake, close the leaf, update back to trunk, and start again. See, for example, http://www.sqlite.org/src/timeline?r=mistake Tomek * - I think it would be somehow possible to get the artifact # and shun it, so technically, it is possible. But there is no command for it. The intent of Fossil is to preserve history, not delete it. Hence, there is no easy way to delete a branch. Shunning is intended as an emergency mechanism to remove content that should have never gotten into the repository in the first place - things such as wiki or ticket spam. Shunning is not intended to remove content just because you think it is obsolete. Mark it as a mistake, as Tomek suggests above. But don't destroy history. On Fri, Sep 30, 2011 at 4:01 PM, Erlis Vidal er...@erlisvidal.com wrote: I'm sorry for this so n00b question but I'm not able to find this anywhere. Is it possible to delete a branch? I've created a branch by mistake, in this case I don't want to merge the branch, I'm looking for the git equivalent -f (force delete) Thanks, Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On 1 Oct 2011, at 15:28 , Stephan Beal wrote: On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal p...@planet.nl wrote: Maybe you could do some http-over-stdin/stdout, and speak json there. :) Isn't fossil cgi already doing that? A front-end could build the appropriate environment variables and fork/exec fossil cgi, feeding the post body to fossil's stdin. That is basically what server mode does - prepares the cgi environment (including stdin/stdout) and runs it through CGI mode... Yes, and this is what any wrapper program can do. For example, there are folks that would like to have Tcl/Jim with Fossil, I would prefer Javascript and I'm sure there are those who would like Python or PHP. In each of those environments it would be easy to add a command/library function that calls Fossil's json interface through exec'ing Fossil in cgi mode. Tcl etc. would be wrapped around Fossil, rather than Fossil wrapped around the language and that way everybody can have their preferred language without further bloat in the Fossil binary. Doing fork/exec sounds expensive, but on a posix box there is not much difference between that and spawning a thread: http://bulk.fefe.de/scalable-networking.pdf (where output is very controlled (entirely buffered) because no body text may be sent before the headers are sent). The majority of the parameter handling in all of the fossil commands relies on the environment having a fresh state for each request, which means the whole environment, GET, POST, and everything, needs to be reconstructed before each commands. e.g. the way a given command is invoked is based on the request path (an environment variable), which can only be set to one value for any given invocation of server/CGI mode. There is no mechanism (in the current code base) with which we can simply re-set the whole environment and run a different command. Yes, and why would that be difficult to handle for a wrapper (see below)? after every command fossil runs, exit() is called somewhere, which makes it difficult or impossible to chain commands together in the same app session. Why? The same reason attempts to adding a shell mode for fossil have failed so far. Almost every error condition in fossil passes through fossil_fatal() or similar, and that ends up calling exit(). So if you add a command and use any of the db functions, and those hit any errors at all, your command will end up exit()ing. If you mean why does it exit() so much? That's just the way it was originally designed - historic momentum. For fossil's original purpose (and its current primary uses), the current model actually works quite well, and simplifies some of the trickier handling needed when producing HTML output (e.g. the buffering of the body and headers, and sending them out at the proper times). There is of course lots of interest in refactoring fossil into a library, but the amount of effort required is huge. It could easily take a few full-time weeks of development effort, and would probably require the assistance of at least one person who's exceedingly familiar with fos sil's more intricate bits (e.g. how artifacts are maintained/linked/created/etc.). While i'm relatively familiar with the code in general, there are huge blocks of voodoo in there i won't touch for fear of breaking them. My questions was indeed the former: why do the calls to exit make it difficult or impossible to chain commands -- there would simply be a chain of CGI calls and if one step fails the wrapper has to decide what to do next, just as it would have to do when a classic API call fails. My question was not the latter (why does it exit on exceptions). Richard calls it vintage unix thinking, but I think it is equally valid in a RESTfull design -- perhaps any design. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set up a server under nginx ?
OK. Well, the other thing you can do is lobby the nginx people to start supporting CGI. :-) I'm not a nginx user, and such would not work if the front web server and the fossil server are on different machines, as they are in my case. With the current fossil code base my workaround is to run a tiny webserver on the fossil machine that calls fossil in CGI mode and sets the SCRIPT_NAME environment variable appropriately based on the forwarded http header info. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil ui does not launch
As you may guess from my previous email, it might be that it is something with the repos which were darcs -- fossil converted via git and/or with FF 'stale' session. Perhaps it is an obscure race condition between fossil initialising the server socket and FF4 opening a client socket to that server socket. With Windows XP and IE7 it would happen that IE would hang if it opened before a wifi network connection was fully initialised. You may want to try adding a 'sleep(1)' or so to fossil to test this hypothesis. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil social networking
Can you link me some info on the hooks? I didn't need them for the social networking stuff, but something like server-side scripting with scripts in the repository would be very nice. TH1 is good for templating, but personally, I'd like a full language -- a complete TCL or Lua or something like that. I'm working on a small, but full javascript 1.5 implementation which should be ready this Summer. It's about 7.000 lines of C and compiles to a 140kb binary on x86. That's substantially larger than TH1 (which is a 45kb or so binary). It might be a nice addition to Fossil, but I think that Richard might prefer TCL. That being said, I'm opposed to bloat and function creep in Fossil. Perhaps what is needed is a small companion to Fossil that acts as a hub server. That companion could be a webserver / sqlite / javascript combo, which either reads the database files direct, or calls out to Fossil to perform its operations. Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Keyword Expansion?
fossil and sqlite solve that somehow by being compiled :-) -- they just
compile the information from those manifest files in their final
executable, but thats not a reasonable approach for scripts that are
executed by an interpreter.
Actually, both fossil and sqlite use their build interpreter ('make' and
'tcl' respectively) to process the manifest files into source code. What
stops your interpreter from doing the same? It could perform all the
functions you require, perhaps using additional info made available through
the manifest.
Personally I've always considered 'in source' markers as a bad hack,
rooted in now ancient tools (SCCS/1972 and RCS/1982). I'm not against the
idea per se, but I would like to understand your requirements better. Could
you elaborate?
Thanks,
Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] user/pass login with https?
I see. Right - fossil sync does not have any idea how to do LDAP authentication. I guess LDAP credentials are stored in the browser somehow. But fossil sync bypasses the browser completely. So I guess it will somehow need to understand some kind of LDAP authentication protocol and reauthenticate? Can anybody explain to me how that works, or perhaps give a link to a reasonable tutorial? Does anybody have an LDAP implementation that I can test against? I think he is using http authentication (e.g. http://en.wikipedia.org/wiki/Basic_access_authentication), with ldap only providing the right password to the http server. That is how I understood his question. Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scgi for Linux
Finally found the time to work a little on implementing the backend
command that I proposed a few weeks ago. Please find a patch attached.
I've chosen a rather minimal approach. Also, it currently only does the
http
version.
fossil backend [-P port|pipe] [-F front-server-ip] [repository]
Fossil backend mainly operates like fossil server, with a little more
added in:
- Auto login is disabled
- Only if the request is comming from the front server IP:
. X-Forwarded-For is honoured, single ip only (i.e. no forwarding
chains)
. If X-Forwared-For is present, X-Fossil-BaseUrl is honoured; this is
the base path to use (similar to cgi's script_name)
- Requests coming from all other IP's are treated as if the command had
been fossil server; this way local, in-company traffic works as before
and public access can be proxied out to the web, all from one fossil
server.
If there is interest in this patch for the main trunk I'll send the
copyright release etc. I'll also add scgi support to the command, using
the idea of looking at the first character when parsing the request
header. If
there are security concerns with this approach, please advise.
All input constructive criticism welcome!
Thanks,
Paul
PS: I don't quite understand why the notfound path is appended to the
client ip in the win http server code. It seems to me this is unused, but
perhaps I'm missing something.
On Tue, 08 Jun 2010 08:41:57 +0200, Paul Ruizendaal p...@planet.nl wrote:
Have thought about it some more, but no security epiphany. My view
remains
that the command should be something like this:
fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R
repository]
Semantics could be:
- all requests coming from a client other than the front-server-ip (fip)
are denied with a 403 forbidden response.
- all requests that specify a real client ip of 127.0.0.1 are denied
with
the same response
- For http, X-Forwarded-For only looks at the first (ultimate client)
ip;
if ommitted the fip is used
- For http, it sets the base url to X-Fossil-BaseUrl; if ommitted the
base
url is root
- For scgi, the client ip is set to the client ip header which must be
present (at penalty of 400 bad request)
- For both, REMOTE_USER is honoured
Variations could be to add any to http|scgi to serve both at the same
time, or to make acceptance of remote user a feature that must be
enabled
with an additonal flag. I think hope that the above can be done in a
small patch, a I remain opposed to adding bloat to Fossil.
Will that work for security and convience? Input welcome.
Index: src/cgi.c
===
--- src/cgi.c
+++ src/cgi.c
@@ -656,24 +656,41 @@
/*
** Initialize the query parameter database. Information is pulled from
** the QUERY_STRING environment variable (if it exists), from standard
** input if there is POST data, and from HTTP_COOKIE.
+** If we are running as a backend server and this request comes from the
+** front server, then check and use the HTTP_X_FORWARDED_FOR header, otherwise
+** stick to the REMOTE_ADDR as the client IP address. If the Forwarded-For
+** header is present, also check for the X-Fossil-BaseURL header, which
+** becomes the base location for generated html links, similar to the script
+** path for regular cgi usage of Fossil.
*/
void cgi_init(void){
- char *z;
+ char *z, *zz;
const char *zType;
int len;
cgi_destination(CGI_BODY);
z = (char*)P(QUERY_STRING);
if( z ){
z = mprintf(%s,z);
add_param_list(z, '');
}
- z = (char*)P(REMOTE_ADDR);
- if( z ) g.zIpAddr = mprintf(%s, z);
+ z = (char*)P(REMOTE_ADDR);
+ zz = (char*)P(HTTP_X_FORWARDED_FOR);
+ if( zz g.zFrontIP z inet_addr(z)==inet_addr(g.zFrontIP) ){
+/* The next statements cannot be reached for regular cgi usage, but
+ * only when acting in backend server mode. */
+g.zIpAddr = mprintf(%s, zz);
+zz = strchr(g.zIpAddr, ',');
+if( zz ) *zz = 0;
+zz = (char*)P(HTTP_X_FOSSIL_BASEURL);
+if( zz ) cgi_replace_parameter(SCRIPT_NAME, zz);
+ }else{
+if( z ) g.zIpAddr = mprintf(%s, z);
+ }
len = atoi(PD(CONTENT_LENGTH, 0));
g.zContentType = zType = P(CONTENT_TYPE);
if( len0 zType ){
blob_zero(g.cgiIn);
@@ -1138,10 +1155,14 @@
cgi_setenv(HTTP_COOKIE, zVal);
}else if( strcmp(zFieldName,if-none-match:)==0 ){
cgi_setenv(HTTP_IF_NONE_MATCH, zVal);
}else if( strcmp(zFieldName,if-modified-since:)==0 ){
cgi_setenv(HTTP_IF_MODIFIED_SINCE, zVal);
+}else if( strcmp(zFieldName,x-forwarded-for:)==0 ){
+ cgi_setenv(HTTP_X_FORWARDED_FOR, zVal);
+}else if( strcmp(zFieldName,x-fossil-baseurl:)==0 ){
+ cgi_setenv(HTTP_X_FOSSIL_BASEURL, zVal);
}
}
cgi_init();
}
Index: src/http_transport.c
===
--- src/http_transport.c
+++ src/http_transport.c
@@ -173,11 +173,11 @@
*/
void transport_flip
Re: [fossil-users] scgi for Linux
Have thought about it some more, but no security epiphany. My view remains that the command should be something like this: fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] Semantics could be: - all requests coming from a client other than the front-server-ip (fip) are denied with a 403 forbidden response. - all requests that specify a real client ip of 127.0.0.1 are denied with the same response - For http, X-Forwarded-For only looks at the first (ultimate client) ip; if ommitted the fip is used - For http, it sets the base url to X-Fossil-BaseUrl; if ommitted the base url is root - For scgi, the client ip is set to the client ip header which must be present (at penalty of 400 bad request) - For both, REMOTE_USER is honoured Variations could be to add any to http|scgi to serve both at the same time, or to make acceptance of remote user a feature that must be enabled with an additonal flag. I think hope that the above can be done in a small patch, a I remain opposed to adding bloat to Fossil. Will that work for security and convience? Input welcome. Paul On Wed, 2 Jun 2010 23:27:57 +0100, Owen Shepherd owen.sheph...@e43.eu wrote: On 2 June 2010 18:11, Joshua Paine jos...@letterblock.com wrote: Only 127.0.0.1 is privileged, right? So can we just not trust X-Forwarded-For: 127.0.0.1 no matter who says it, and not worry if X-Forwarded-For is abused otherwise? No. Fossil keys its login cookies off the user's IP address. If the user can provide X-Forwarded-For, then stealing a cookie becomes a lot more useful. fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scgi for Linux (was: Fossil behind proxy)
DRH wrote: Here again, we need to be mindful of security. Miscreants can easily forge an x-forwarded-for: line in an HTTP request and in the default configuration Fossil allows requests requests from 127.0.0.1 to bypass the login mechanism. (That login bypass for 127.0.0.1 makes the fossil ui command much more convenient.) So at the very least, we would want to check the value supplied by x-forwarded-for and make sure it is not 127.0.0.1. In addition, we might want to disregard x-forwarded-for completely unless the real REMOTE_ADDR is 127.0.0.1, or perhaps some other well-known address specified on the fossil server or fossil http command-line. In other words, disregard x-forwarded-for unless the request is coming from a known trusted host. I accept your points on security. When used on a company network (in a larger company), the fossil scgi command needs to be limited to trusted clients as well. I think it is worth thinking about the commands, so that they remain understandable and intuitive also for new or casual users. Currently I'm thinking along the lines of three forms of the server command. Now we have fossil server and fossil ui, which should stay as is. Perhaps it needs a third form along the lines of: fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] Not sure yet, I'll think about it a bit more. All input welcome. Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scgi for Linux (was: Fossil behind proxy)
Well, I'll try to review your patch next weekend and see where the Windows issues might be. I've had an early chance to look at your patch and to learn the SCGI protocol. Please find my remarks below. [1] Perhaps I'm thick as a brick, but my understanding of the SCGI protocol is that it does not support interleaving and does not support keep-alive. So, philosophically, I'm back to my original position that http proxying is the most elegant solution. That being said, your patch is quite small, so I am less concerned. However, I think it can be improved. [2] The windows server doesn't use fork(). It reads the socket into a file, and then exec's a fossil http command, with input and output redirected to files. Once the child finishes, the output file is read and written to the socket. The reason for this is that on windows read() is not acting as recv() when the file descriptor is a socket. Other solutions exist, but none as simple as this solution. fossil http does some prelim work, but ends up calling cgi_handle_http_request(). [3] So, the cleanest solution may be the following. If you have cgi_handle_http_request() recognise whether it is reading a http or an scgi request (which is easy: an http request starts with an ascii letter and an scgi request starts with an ascii decimal digit) and make it handle both forms, you will have added SCGI support for all platforms. [4] This has the added advantage that no new command is needed: fossil server will do both http and scgi at the same time. You can add the unix domain socket code to the fossil server command if needed. The name of the fossil http command becomes a bit of a misnomer as it does more, but I don't think that this is a problem. [5] Your improvement to the Posix server code does not harm the Windows server code and to me it looks like it should run on all Posix systems (but I have not tested this). [6] Your patch was a quick project and it shows. Commenting could be better, if accept() fails for another reason than EINTR the server hangs, etc. [7] In the odd case that I actually convinced you that http proxying is a better solution than SCGI for integrating a fossil repo into a larger website, adding support for X-Forwarded-For is just a few extra lines of code in cgi_init(): z = (char*)P(REMOTE_ADDR); if( z ) g.zIpAddr = mprintf(%s, z); + z = (char*)P(X_FORWARDED_FOR); + if( z ) g.zIpAddr = mprintf(%s, z); Hope the above has been of help. For the avoidance of doubt: you will have to convince DRH to accept your patch, not me; I'm just a user. Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil for dummies PDF
Jim, I'd be happy to merge in my write-up about the TH1 script language. Howver, that is not quick start guide material, and perhaps is outside the focus of the document. Paul On Sat, 29 May 2010 06:20:01 -0400, Jim Schimpf jim.schi...@gmail.com wrote: Hi, I've been working on this for a while and thought it might be useful for the group. This is a PDF for a new user of Fossil to show them how to use it in a simple project. It's not for most of the people on this list who know much more than I about Fossil. It is meant to be something you can give to the friend who just wants to use Fossil for his projects. The online documentation on the Fossil site is very good and I used the ideas there for some of the book but personally I really like having a PDF with an active index and TOC for documentation. Here is the site: http://pandora.dyn-o-saur.com:8080/cgi-bin/Book.cgi (it's served by Fossil, naturally). If you have comments or want to add to this let me know and I can give you a login and of course credit in the text. I would very much appreciate your comments on what I did or did not do correctly and how it can be improved. --jim schimpf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scgi for Linux (was: Fossil behind proxy)
Hi folks, Two remarks: 1. I'm happy that more and more people are contributing to Fossil, but I'm also a bit concerned about the increasing Posix dependence. The https code builds in a dependence on libssl, and now the below patch is Posix only. The cross-platform nature of Fossil is important to me, as is the small binary (i.e. no dependence on cygwin, wine, jre, ...) 2. What is the added value of scgi? What can scgi do that http can't? What I mean is, running Fossil as http server and configuring the front server (ngix in the original post) as a reverse proxy solves the exact same problem without any need for additional code. Perhaps I'm missing the point, but to me adding scgi is bloat. Paul On Sun, 30 May 2010 21:23:59 +0100, Owen Shepherd owen.sheph...@e43.eu wrote: I've finished modifying Fossil to support SCGI. Some notes: - I rewrote the accept loop of the server/ui command at the same time. It no longer uses select with a timeout in order to reap child processes; instead, a signal handler is installed for SIGCHLD in order to reap them and maintain the child process count. This both means Fossil doesn't wake up pointlessly every 60 seconds, and that the code is much simpler. - Instead of calling sleep when too many connections have been established for an arbritary time period with a minimum length of 2 seconds, we call pause() until the number of connections drops to a satisfactory level. (In fact, both SCGI and HTTP modes share an accept loop). fossil scgi performs admirably behind Apache with mod_scgi. It works fine for GET requests behind nginx' mod_scgi; but POST requests cause it to lose its marbles. This is an issue on nginx' end; I'll have to look into that. scgi is currently only supported on !win32 because I don't have any experience with winsock. Additionally, as with Fossil's standard server handler, it depends upon fork. Support is provided for both TCP and Unix domain sockets. Which to use is determined by whether the port parameter is an integer or not. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scgi for Linux (was: Fossil behind proxy)
The biggest issue with HTTP 1.1 for backend communication is long running connections since HTTP doesn't support interleaving. Now that I find a convincing argument! Can you confirm from your experience that SCGI is not broken in this respect in the same way as FastCGI (i.e. the protocol spec defines it, but most code doesn't implement it or is broken)? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repository-dependant cookies
I wish it served a page at the root that listed all hosted repositories. Would it be a security problem to do that? I thought it would be. Perhaps not in every instance, but I can envisions scenarios where a user would not want that listing to appear. The standard solution of web servers is to see if index.html exists in the directory and if so, serve that page; if not a 404 results. Many servers have the option to do a listing, but that is just that: an option. Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil behind reverse proxy
if
fossil had a loopback-only setting similar to postfix's to bind its
socket listener to only localhost IPv4/IPv6 interfaces).
If you want your fossil URL to look like http://some_machine/foo/bar/
scm you need would change the above example lines for starting your
fossil server and setting your Apache configuration as follows:
SCRIPT_NAME=/foo/bar/scm
ProxyPass /foo/bar/scm http://
machine_your_fossil_server_is_running_on:8000
Similarly you can change the port the fossil server runs on just as
easily.
It turns out that since fossil already handles running from an
arbitrary web location as a cgi script, it quite happily will still
use that arbitrary location when running as a server if you provide it
via SCRIPT_NAME.
I wish there was functionality something like this though:
fossil server -P 8000 --ext .fsl
path_to_directory_containing_.fsl_repositories
Where a single fossil server could serve up multiple fossil
repositories. You would just point it to the parent directory and
tell it what repository extension to look for and then it would insert
an additional element into the URL using the base name of the fossil
repository minus the extension. So if you had these repositories on
your system:
/some/directory/repository1.fsl
/some/directory/repository2.fsl
And started the fossil server like this:
fossil server -P 8080 --ext .fsl /some/directory
Then you could access repository1.fsl like this:
http://localhost:8080/repository1
and repository2.fsl like this:
http://localhost:8080/repository2
and as a bonus you could get a list of available repositories with this:
http://localhost:8080/
(And, of course, still use the SCRIPT_NAME trick to change the URL
location if you like.)
I believe a relatively simple Perl or Python server script could use
the fossil http command to implement the multiple repository server
relatively easily since the SCRIPT_NAME technique also works with the
fossil http command. Hmmm, I might just have to write that script
later today.
Kyle
On Jan 28, 2010, at 04:00, Paul Ruizendaal wrote:
It may be subtler and easier than I first thought:
Fossil already uses the host information from the Host: header, not
from
its own IP. When in CGI mode, it already relocates all its absolute
references to include the prefix of the cgi script location.
When running as server Fossil does not do the above relocation but
keeps
everyting based at root ('/'), regardless of the path in the request
uri.
Is there a reason that makes fossil CGI style relocation a bad idea
for a
fossil running in server mode?
Paul
==
I just tried to put Fossil (running as server) behind a reverse proxy
(home grown, but similar to Pound).
That doesn't work very well, because Fossil prefixes all paths in its
output with a full baseURL (as seen by Fossil). The client can't use
that
as the reverse proxy maps an entirely different prefix to the Fossil
server
instance. I think the html/css output by Fossil should use relative
paths,
not absolute paths.
Next to the above, also the 301 Redirect repsonses have the wrong
url, but
that is as per the http RFC: it is a reasonable job for a reverse
proxy to
rewrite the Location: header of a 301 response.
Before I attempt this rather massive patch: Richard, any remarks?
Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil behind reverse proxy
I just tried to put Fossil (running as server) behind a reverse proxy (home grown, but similar to Pound). That doesn't work very well, because Fossil prefixes all paths in its output with a full baseURL (as seen by Fossil). The client can't use that as the reverse proxy maps an entirely different prefix to the Fossil server instance. I think the html/css output by Fossil should use relative paths, not absolute paths. Next to the above, also the 301 Redirect repsonses have the wrong url, but that is as per the http RFC: it is a reasonable job for a reverse proxy to rewrite the Location: header of a 301 response. Before I attempt this rather massive patch: Richard, any remarks? Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil behind reverse proxy
It may be subtler and easier than I first thought:
Fossil already uses the host information from the Host: header, not from
its own IP. When in CGI mode, it already relocates all its absolute
references to include the prefix of the cgi script location.
When running as server Fossil does not do the above relocation but keeps
everyting based at root ('/'), regardless of the path in the request uri.
Is there a reason that makes fossil CGI style relocation a bad idea for a
fossil running in server mode?
Paul
==
I just tried to put Fossil (running as server) behind a reverse proxy
(home grown, but similar to Pound).
That doesn't work very well, because Fossil prefixes all paths in its
output with a full baseURL (as seen by Fossil). The client can't use that
as the reverse proxy maps an entirely different prefix to the Fossil
server
instance. I think the html/css output by Fossil should use relative paths,
not absolute paths.
Next to the above, also the 301 Redirect repsonses have the wrong url, but
that is as per the http RFC: it is a reasonable job for a reverse proxy to
rewrite the Location: header of a 301 response.
Before I attempt this rather massive patch: Richard, any remarks?
Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
