Update of "checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.


Artifact ID: 7de02241e8ea8bb688137c47caa4fa607d0961784be0173077b09ee0fadebaf0
Page Name:checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6
Date: 2019-04-06 19:18:05
Original User: drh

Suppose the Fossil server is being run as a CGI script named "index.html" or perhaps "index.cgi". Let the domain be "". If a user visits the main website at, the web server will automatically redirect to which will then run Fossil and all is well. But, prior to this change, if you tried to clone using

 fossil clone ex.fossil

Then the HTTP request for the clone would go to The web server would not normally know to redirect that request to unless someone made special provisions in the web server setup, which is unlikely. Thus, the clone would fail.

After this change, the clone and sync HTTP requests go to the URL as stated on the command line, with no additions. Thus the web server can supply an appropriate 302 redirect. The prior check-in from 2010 knows to automatically append the /xfer path element to any inbound request that has a mimetype of application/x-fossil. And so all will be well, as long as the server has been updated at least once in the previous 9 years. But this means that using a recent Fossil client against a really old Fossil server will break unless the URL for the sync is changed to explicitly include the /xfer path element at the end.

Hopefully this will never come up, but I thought it important do document the issue here, in case it does.