Discussion:
Repository-dependant cookies
(too old to reply)
r***@stumvolls.de
2010-01-30 13:24:50 UTC
Permalink
Hello

I'm hosting more than one repository on a single machine. I have to
logon everytime, when i change in my browser from one to another
repository.

Would it be possible to have a Login-Cookie for every repository? I
think the Cookie-name should have a repository-dependend part.

Thanks
Wolfgang
Stephen De Gabrielle
2010-01-30 14:18:41 UTC
Permalink
I can't answer your question, but you can run each server on a different port.

Stephen

On Saturday, January 30, 2010, <***@stumvolls.de> wrote:
> Hello
>
> I'm hosting more than one repository on a single machine. I have to
> logon everytime, when i change in my browser from one to another
> repository.
>
> Would it be possible to have a Login-Cookie for every repository? I
> think the Cookie-name should have a repository-dependend part.
>
> Thanks
> Wolfgang
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

--

--
Stephen De Gabrielle
***@acm.org
Telephone +44 (0)20 85670911
Mobile +44 (0)79 85189045
http://www.degabrielle.name/stephen
D. Richard Hipp
2010-01-30 14:40:58 UTC
Permalink
On Jan 30, 2010, at 8:24 AM, <***@stumvolls.de>
<***@stumvolls.de> wrote:

> Hello
>
> I'm hosting more than one repository on a single machine. I have to
> logon everytime, when i change in my browser from one to another
> repository.
>
> Would it be possible to have a Login-Cookie for every repository? I
> think the Cookie-name should have a repository-dependend part.

That is the way it is currently implemented.

I host about 2 dozen repositories on http://www.sqlite.org (examples: http://www.sqlite.org/src
, http://www.sqlite.org/docsrc, http://www.sqlite.org/br3317) and my
browser (Firefox) keeps separate cookies for each. Are you saying
this does not work for you?


>
> Thanks
> Wolfgang
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

D. Richard Hipp
***@hwaci.com
r***@stumvolls.de
2010-01-30 17:33:39 UTC
Permalink
Hello again

Here are some more informations about my configuration:

* Server OS: Windows Home Server(Windows 2003 based)
* running two different fossil repositories on ports 8000 and
8001(Fossil version [a3c97c9063] 2010-01-21 20:53:59)
* client OS: XP prof.
* Browser: Firefox 2

If i switch between the repositories, the current login becomes invalid.

I opened the cookie-dialog of firefox. There i can see One cookie from
my server, named
fossil_login_

I think the problem is, that there is no 'repository-extension' behind
the last underscore.

The test_env-information, given by one of the servers is:
g.zBaseURL = http://<DELETED BY ME>:8000
g.zTop =
GATEWAY_INTERFACE = CGI/1.0
HTTP_COOKIE =
fossil_login_=1%2F5A300CEC00A1528DAE8F21FD975FE6742534E95E2D2443872E
HTTP_HOST = <DELETED BY ME>:8000
HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 (.NET CLR 3.5.30729)
PATH_INFO = /test_env
QUERY_STRING =
REMOTE_ADDR = <DELETED BY ME>
REQUEST_METHOD = GET
REQUEST_URI = /test_env
fossil_login_ = <DELETED BY ME>

Maybe this information helps. Feel free to contact me, if you need
further information.

Wolfgang
D. Richard Hipp
2010-01-31 03:21:13 UTC
Permalink
On Jan 30, 2010, at 12:33 PM, <***@stumvolls.de>
<***@stumvolls.de> wrote:

> Hello again
>
> Here are some more informations about my configuration:
>
> * Server OS: Windows Home Server(Windows 2003 based)
> * running two different fossil repositories on ports 8000 and
> 8001(Fossil version [a3c97c9063] 2010-01-21 20:53:59)
> * client OS: XP prof.
> * Browser: Firefox 2
>
> If i switch between the repositories, the current login becomes
> invalid.
>
> I opened the cookie-dialog of firefox. There i can see One cookie from
> my server, named
> fossil_login_

I guess firefox 2 sends to same cookie to port 8001 as it sends to
port 8000. as if localhost:8000 and localhost:8001 were the same
website.

If you switch to running a webserver (on port 80, say) and run your
repositories as CGI scripts, the names of each CGI script will be
appended (as hex) to the login cookie name and this problem will go
away. It is not clear to me what (if anything) we ought do to Fossil
to make it easier to work around this.

There was another recent request for the ability to serve multiple
repositories off of the same TCP port without using a web server. The
current syntax to launch a stand-alone server is:

fossil server REPOSITORYFILE

Suppose we expanded this to allow multiple repositories to be named on
the command-line. So if you had a directory full of repositories, you
could do:

fossil server *.fossil

Suppose the names of the repositories files are abc.fossil,
def.fossil, ghi.fossil and so forth. Then to reach each repository,
visit:

http://localhost/abc
http://localhost/def
http://localhost/ghi

And so forth. If this functionality were implemented, then the cookie
names would be fossil_login_2F616263, fossil_login_2F646566, and
fossil_login_2F676869. Since the cookie names are different, you
could log onto all repositories all at once. If no repository is
specified in the URL (if you enter http://localhost/) what should it
do? Show an error? Return a list of repositories? Choose the first
one named?

Perhaps the syntax should be:

fossil server --directory FOLDER_HOLDING_REPOSITORIES

In that case, fossil is able to serve any fossil repository in the
named directory. The particular repository chosen by the path in the
URL. With this syntax, new repositories can be added to the site
without having to restart the server - simply move files into the
appropriate folder. We still have the problem of what to do with an
unknown path.

>
> I think the problem is, that there is no 'repository-extension' behind
> the last underscore.
>
> The test_env-information, given by one of the servers is:
> g.zBaseURL = http://<DELETED BY ME>:8000
> g.zTop =
> GATEWAY_INTERFACE = CGI/1.0
> HTTP_COOKIE =
> fossil_login_=1%2F5A300CEC00A1528DAE8F21FD975FE6742534E95E2D2443872E
> HTTP_HOST = <DELETED BY ME>:8000
> HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 (.NET CLR 3.5.30729)
> PATH_INFO = /test_env
> QUERY_STRING =
> REMOTE_ADDR = <DELETED BY ME>
> REQUEST_METHOD = GET
> REQUEST_URI = /test_env
> fossil_login_ = <DELETED BY ME>
>
> Maybe this information helps. Feel free to contact me, if you need
> further information.
>
> Wolfgang
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

D. Richard Hipp
***@hwaci.com
Michael Richter
2010-01-31 03:31:10 UTC
Permalink
2010/1/31 D. Richard Hipp <***@hwaci.com>

> There was another recent request for the ability to serve multiple
> repositories off of the same TCP port without using a web server. The
> current syntax to launch a stand-alone server is:
>
> fossil server REPOSITORYFILE
>
> Suppose we expanded this to allow multiple repositories to be named on
> the command-line. So if you had a directory full of repositories, you
> could do:
>
> fossil server *.fossil
>
> Suppose the names of the repositories files are abc.fossil,
> def.fossil, ghi.fossil and so forth. Then to reach each repository,
> visit:
>
> http://localhost/abc
> http://localhost/def
> http://localhost/ghi
>
> And so forth. If this functionality were implemented, then the cookie
> names would be fossil_login_2F616263, fossil_login_2F646566, and
> fossil_login_2F676869. Since the cookie names are different, you
> could log onto all repositories all at once. If no repository is
> specified in the URL (if you enter http://localhost/) what should it
> do? Show an error? Return a list of repositories? Choose the first
> one named?
>
> Perhaps the syntax should be:
>
> fossil server --directory FOLDER_HOLDING_REPOSITORIES
>
> In that case, fossil is able to serve any fossil repository in the
> named directory. The particular repository chosen by the path in the
> URL. With this syntax, new repositories can be added to the site
> without having to restart the server - simply move files into the
> appropriate folder. We still have the problem of what to do with an
> unknown path.
>

I like these ideas a *lot*, Richard. As in I like all of them. For just
quickly sharing a specific repository you use the single-file version (the
default as now). If you want to share specific repositories but not all of
them, the multiple repositories on the command line is perfect. If you want
to host many repositories and expand/contract them as needed without
restarting the server your directory syntax is perfect.

If you enter just the root there's arguments for two approaches:

1. The open approach is to list all the accessible repos.
2. The more security-semi-conscious approach would be to assume someone
hitting the root isn't authorized to access any repository and thus should
gets flipped the bird, metaphorically.
Ron Aaron
2010-01-31 04:58:12 UTC
Permalink
On Sunday 31 January 2010 05:21:13 D. Richard Hipp wrote:

> Suppose we expanded this to allow multiple repositories to be named on
> the command-line. So if you had a directory full of repositories, you
> could do:
>
> fossil server *.fossil
>
> Suppose the names of the repositories files are abc.fossil,
> def.fossil, ghi.fossil and so forth. Then to reach each repository,
> visit:
>
> http://localhost/abc
> http://localhost/def
> http://localhost/ghi

I also like this idea a lot -- it would make my life easier. But -- how does this work for a CGI-based server? I'm having trouble figuring out how it should be set-up...

--
Sending me something private?
Use my GPG public key: AD29415D
D. Richard Hipp
2010-01-31 20:35:56 UTC
Permalink
On Jan 30, 2010, at 10:21 PM, D. Richard Hipp wrote:
>
> Perhaps the syntax should be:
>
> fossil server --directory FOLDER_HOLDING_REPOSITORIES
>
> In that case, fossil is able to serve any fossil repository in the
> named directory. The particular repository chosen by the path in the
> URL. With this syntax, new repositories can be added to the site
> without having to restart the server - simply move files into the
> appropriate folder. We still have the problem of what to do with an
> unknown path.


The implementation of this is in the latest check-in: http://www.fossil-scm.org/fossil/vinfo/9cd2c42e79

There is no --directory option. Instead, just specify a directory
name as the repository and Fossil will automatically use repositories
within that directory, based on the first element of the pathname.
For example:

Folder xyz contains abc.fossil, def.fossil, and ghi.fossil.

fossil server xyz -port 80

Then you can view any of the three projects using URLs:

http://localhost/abc
http://localhost/def
http://localhost/ghi

Note that repository names must in with ".fossil". And the basenames
of the repositories (the part before the ".fossil") may only contain
alphanumeric characters, "-" and "_"; no spaces or other special
characters are allows.

I tested the new functionality on linux and winXP. This feature
currently only works for "server" and "http" commands. It does not
work for "ui" or "cgi".

Please advice if you find any problems.

D. Richard Hipp
***@hwaci.com
Michael Richter
2010-02-01 02:12:01 UTC
Permalink
This is truly awesome, Richard! Thanks a lot.


On 1 February 2010 04:35, D. Richard Hipp <***@hwaci.com> wrote:

>
> On Jan 30, 2010, at 10:21 PM, D. Richard Hipp wrote:
> >
> > Perhaps the syntax should be:
> >
> > fossil server --directory FOLDER_HOLDING_REPOSITORIES
> >
> > In that case, fossil is able to serve any fossil repository in the
> > named directory. The particular repository chosen by the path in the
> > URL. With this syntax, new repositories can be added to the site
> > without having to restart the server - simply move files into the
> > appropriate folder. We still have the problem of what to do with an
> > unknown path.
>
>
> The implementation of this is in the latest check-in:
> http://www.fossil-scm.org/fossil/vinfo/9cd2c42e79
>
> There is no --directory option. Instead, just specify a directory
> name as the repository and Fossil will automatically use repositories
> within that directory, based on the first element of the pathname.
> For example:
>
> Folder xyz contains abc.fossil, def.fossil, and ghi.fossil.
>
> fossil server xyz -port 80
>
> Then you can view any of the three projects using URLs:
>
> http://localhost/abc
> http://localhost/def
> http://localhost/ghi
>
> Note that repository names must in with ".fossil". And the basenames
> of the repositories (the part before the ".fossil") may only contain
> alphanumeric characters, "-" and "_"; no spaces or other special
> characters are allows.
>
> I tested the new functionality on linux and winXP. This feature
> currently only works for "server" and "http" commands. It does not
> work for "ui" or "cgi".
>
> Please advice if you find any problems.
>
> D. Richard Hipp
> ***@hwaci.com
>
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
Wilson, Ronald
2010-02-01 12:24:16 UTC
Permalink
This is great! I wish it served a page at the root that listed all hosted repositories. Would it be a security problem to do that?

RW

Ron Wilson, Engineering Project Lead
(o) 434.455.6453, (m) 434.851.1612, www.harris.com

HARRIS CORPORATION | RF Communications Division assuredcommunications(tm)


> -----Original Message-----
> From: fossil-users-***@lists.fossil-scm.org [mailto:fossil-users-
> ***@lists.fossil-scm.org] On Behalf Of D. Richard Hipp
> Sent: Sunday, January 31, 2010 3:36 PM
> To: fossil-***@lists.fossil-scm.org
> Subject: Re: [fossil-users] Repository-dependant cookies
>
>
>
> On Jan 30, 2010, at 10:21 PM, D. Richard Hipp wrote:
> >
> > Perhaps the syntax should be:
> >
> > fossil server --directory FOLDER_HOLDING_REPOSITORIES
> >
> > In that case, fossil is able to serve any fossil repository in the
> > named directory. The particular repository chosen by the path in the
> > URL. With this syntax, new repositories can be added to the site
> > without having to restart the server - simply move files into the
> > appropriate folder. We still have the problem of what to do with an
> > unknown path.
>
>
> The implementation of this is in the latest check-in: http://www.fossil-
> scm.org/fossil/vinfo/9cd2c42e79
>
> There is no --directory option. Instead, just specify a directory
> name as the repository and Fossil will automatically use repositories
> within that directory, based on the first element of the pathname.
> For example:
>
> Folder xyz contains abc.fossil, def.fossil, and ghi.fossil.
>
> fossil server xyz -port 80
>
> Then you can view any of the three projects using URLs:
>
> http://localhost/abc
> http://localhost/def
> http://localhost/ghi
>
> Note that repository names must in with ".fossil". And the basenames
> of the repositories (the part before the ".fossil") may only contain
> alphanumeric characters, "-" and "_"; no spaces or other special
> characters are allows.
>
> I tested the new functionality on linux and winXP. This feature
> currently only works for "server" and "http" commands. It does not
> work for "ui" or "cgi".
>
> Please advice if you find any problems.
>
> D. Richard Hipp
> ***@hwaci.com
>
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
2010-02-01 12:52:46 UTC
Permalink
On Feb 1, 2010, at 7:24 AM, Wilson, Ronald wrote:

> 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.

D. Richard Hipp
***@hwaci.com
Paul Ruizendaal
2010-02-01 13:55:57 UTC
Permalink
>> 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
Jeremy Cowgar
2010-02-01 14:10:11 UTC
Permalink
wrote:
> >> 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.
>

Hm, an index.html is a great suggestion! (sent mine before reading this one).

Jeremy
D. Richard Hipp
2010-02-01 15:19:14 UTC
Permalink
On Feb 1, 2010, at 9:10 AM, Jeremy Cowgar wrote:

> wrote:
>>>> 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.
>>
>
> Hm, an index.html is a great suggestion! (sent mine before reading
> this one).


If Fossil returns the index.html file, then before long you also want
to return various images and CSS files that index.html references.
And then people will want a way to return favicon.ico. And
robots.txt. And then you will need a way to customize the mimetypes
of the various files. Already here is a feature request to allow the
repositories to have extensions other than ".fossil". How long before
people want the ability to handle multiple domains using the HTTP_HOST
property of the HTTP header?

I do *not* want to turn Fossil into a general-purpose web server and
replacement for Apache. That is not its purpose. We have to draw the
line somewhere, and I propose to draw the line here.

D. Richard Hipp
***@hwaci.com
Michael McDaniel
2010-02-01 15:26:35 UTC
Permalink
On Mon, Feb 01, 2010 at 10:19:14AM -0500, D. Richard Hipp wrote:
>
> On Feb 1, 2010, at 9:10 AM, Jeremy Cowgar wrote:
>
> > wrote:
> >>>> 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.
> >>
> >
> > Hm, an index.html is a great suggestion! (sent mine before reading
> > this one).
>
>
> If Fossil returns the index.html file, then before long you also want
> to return various images and CSS files that index.html references.
> And then people will want a way to return favicon.ico. And
> robots.txt. And then you will need a way to customize the mimetypes
> of the various files. Already here is a feature request to allow the
> repositories to have extensions other than ".fossil". How long before
> people want the ability to handle multiple domains using the HTTP_HOST
> property of the HTTP header?
>
> I do *not* want to turn Fossil into a general-purpose web server and
> replacement for Apache. That is not its purpose. We have to draw the
> line somewhere, and I propose to draw the line here.
>
> D. Richard Hipp
> ***@hwaci.com
>
_______________________________________________


thank you, I agree


--
Michael McDaniel
http://putitgetit.com
s***@gmail.com
2010-02-01 15:39:36 UTC
Permalink
> If Fossil returns the index.html file, then before long you also want
> to return various images and CSS files that index.html references.
> And then people will want a way to return favicon.ico. And
> robots.txt. And then you will need a way to customize the mimetypes
> of the various files. Already here is a feature request to allow the
> repositories to have extensions other than ".fossil". How long before
> people want the ability to handle multiple domains using the HTTP_HOST
> property of the HTTP header?
>
> I do *not* want to turn Fossil into a general-purpose web server and
> replacement for Apache. That is not its purpose. We have to draw the
> line somewhere, and I propose to draw the line here.

I completely agree. Stick to your knitting, as they say.

Maybe someone who has need for this type of setup could write a quick tutorial on getting something like lighthttpd or something equally light weight and self-contained set up for local use.

With 2 line apache CGI setup, I'm not sure how much easier it could get if you really need to run on a normal server.

S
Michael Richter
2010-02-02 04:59:38 UTC
Permalink
On 1 February 2010 23:19, D. Richard Hipp <***@hwaci.com> wrote:

> I do *not* want to turn Fossil into a general-purpose web server and
> replacement for Apache. That is not its purpose. We have to draw the
> line somewhere, and I propose to draw the line here.
>

Absolutely agreed. The feature is cool and renaming my repos to *.fossil is
a minor task. If I want a fuller web experience, I'll use a web server and
CGI -- like I already do, in fact. :)
Jeremy Cowgar
2010-02-01 14:09:00 UTC
Permalink
"D. Richard Hipp" <***@hwaci.com> wrote:
> On Feb 1, 2010, at 7:24 AM, Wilson, Ronald wrote:
>
> > 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.
>

Maybe that could be a command line option, so if they want it, they can give -list or something. You could even make it fancy, -list "abc,def,xyz" which will leave out 123 and 456.

Just thinking out loud.

Jeremy
r***@stumvolls.de
2010-01-31 09:49:39 UTC
Permalink
Hello

It's the same with Firefox 3. I think, the problem is the name of the
cookie, requested by the fossil-server (running in server-mode, i didn't
get it work with IIS/cgi :-( ).

You should always add a repository specific extension(Hash of the
repository path?) to the cookie-name, like mentioned in:

> Suppose the names of the repositories files are abc.fossil,
> def.fossil, ghi.fossil and so forth. Then to reach each repository,
> visit:
>
> http://localhost/abc
> http://localhost/def
> http://localhost/ghi
>
> And so forth. If this functionality were implemented, then the cookie

> names would be fossil_login_2F616263, fossil_login_2F646566, and
> fossil_login_2F676869.

Should the repository-part of the URL be the first part of the filename,
or should there be a configuration in the admin section to overwrite the
default URL-part? I don't know :-)

Though it's not a must have, i like the idea of one fossil.exe server
instance serving multiple repositories. In this case, you need the above
extension too :-)

The combination of
1 single file repository
2 multiple repositories on the command-line
3 one directory on the command line
would be ok for me. In case 2 and 3, i would prefer to send a 'directory
listing forbidden', if someone request data for the root without giving
a repository-path. The only case, when requesting data for the root
would be the case 1 - or case 2, if a wildcard only returns one
repository.
A list of available repositories could be send too, but this should be
configurable in the admin part with an option 'Send repository list OR
send directory listing forbidden'.

The cgi-variant could be expanded in the same way. The extension to the
command-line of the server has to be copied to the 'cgi-file',
containging the repository paths(multiple lines for different
repositories or a special markup for a directory.

Best regard
Wolfgang
r***@stumvolls.de
2010-02-01 19:44:25 UTC
Permalink
>> I do *not* want to turn Fossil into a general-purpose web server and

>> replacement for Apache. That is not its purpose. We have to draw
the
>> line somewhere, and I propose to draw the line here.
>
>I completely agree. Stick to your knitting, as they say.
>
>Maybe someone who has need for this type of setup could write a quick
tutorial on getting
> something like lighthttpd or something equally light weight and
self-contained set up
> for local use.

I completely agree too.

At the moment, i'm using 2 "fossil server" instances to serve to
repositories on a Windows Home Server on two different ports.

I added http://urlrewriter.codeplex.com/ to my IIS-configuration and
using the following rules to rewrite the URLs like in apache. After
switching two the new multi-repository-server, i've only to modify the
replacements rules. In the same way, i could add a list-repository-page,
just by adding a corresponding rule.

RewriteRule ^/fossilscm$ fossilscm/index [QSA,NC,R]
RewriteRule ^/fossilscm(/?.*)$ http://<servername>:8001$1 [QSA,NC,P]
RewriteRule ^/fossil$ fossil/index [QSA,NC,R]
RewriteRule ^/fossil(/?.*)$ http://<servername>:8000$1 [QSA,NC,P]

So i call
http://<servername>/wiki
And get
http://<servername>:8000
Where my fossil repo lives :-)

In the future, the rule 2 would be changed to
RewriteRule ^/fossilscm(/?.*)$ http://<servername>:8000/fossilscm/$1
[QSA,NC,P]

Many Thanks
Wolfgang
Continue reading on narkive:
Loading...