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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
