Fossil

Notes About Check-in 19c60b7fc9
Login

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

 fossil clone https://example.org ex.fossil

Then the HTTP request for the clone would go to https://example.org/xfer. The web server would not normally know to redirect that request to https://example.org/index.cgi/xfer 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.