I've resolved this. I'll share my outcome for future folks who want to get a low-maintenance fossil HTTPS server up quickly.
The initial scheme was to use 'stunnel' as a reverse proxy to terminate SSL, and forward the request on to the fossil web server daemon that is listening on the same box. Here's the stunnel config I initially came up with: ===== pid = /home/fossil/stunnel.pid [fossil-https] accept = 10443 cert = /home/fossil/mysite.com.pem connect = localhost:10080 ===== And, again, here is how I was running fossil: /usr/local/bin//fossil server /home/fossil/repo.fossil -P 10080 --baseurl https://mysite.com:10443/ The baseurl here is required under this scheme. If it were not given, then when fossil sends a redirect page it would send urls like http://mysite.com:10080/, because fossil thinks it is speaking HTTP and that the server is on port 10080. So the remote browser would follow the redirect to the wrong L4 endpoint. The thing mostly works, except that it does not handle the extra slash it receives in some URLs, e.g. on the links from the Admin page. (I believe fossil's name resolution behavior here is defensible under RFC2616, by the way -- the RFC says that you compare URLs octet-for-octet with one narrow exception that does not apply here. So, in other words, adding a slash to a URL path changes the URL. So the problem was the URL my browser is sending in the first place, or in the URL that fossil was putting in the HREF in the HTML it was serving.) I considered chasing this further by hacking in the code or looking at getting a "real" industrial web server up. But I saw that DRH had responded to some previous question that the official fossil web site itself is also served by HTTPS, which made me think I was overcomplicating things. So I tried going for a different scheme in which stunnel behaves a bit more like xinetd, and used fossil's supporting feature for that: ===== pid = /home/fossil/stunnel.pid output = /home/fossil/stunnel.log [fossil-https] accept = 10443 cert = /home/fossil/mysite.com.pem exec = /usr/local/bin/fossil execargs = fossil http /home/fossil/repo.fossil --https --host mysite.com:10443 ===== I.e. fork one fossil process per request. This appears to Just Work and is probably what the fossil devs had initially intended. >From a look at the code, by the way, the "--https" argument there is required to prevent fossil from thinking that it should not authenticate the user. Eric On Wed, Jul 24, 2013 at 10:06 PM, Andy Bradford < amb-sendok-1377309999.cdeapjlkdpclmgfol...@bradfords.org> wrote: > Thus said Eric Rubin-Smith on Wed, 24 Jul 2013 10:55:24 -0400: > > > Am I doing something wrong with my configs, or is a code change > > warranted? > > That's hard to say since I don't know under what conditions --baseurl is > intended to be used (I know the docs say reverse proxy, but I haven't > ever set one up so I don't understand all the fine details). The one > time I tried to use it, I was doing it wrong: > > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12107.html > > In my case, however, I was using ``fossil http'' not ``fossil server'' > and when I got rid of the --baseurl option, things worked as expected. > > In your case, you are trying to setup a reverse proxy... if you could > provide some details about to setup a reverse proxy similar to your > configuration (perhaps it is done with Apache), it might be easier for > someone to reproduce. > > Have you tried using it without --baseurl? If so, what happened? > > Thanks, > > Andy > -- > TAI64 timestamp: 4000000051f08852 > > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
