Artifact [7de02241]

Artifact 7de02241e8ea8bb688137c47caa4fa607d0961784be0173077b09ee0fadebaf0:

Wiki page [checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6] by drh 2019-04-06 19:18:05.
D 2019-04-06T19:18:05.747
L checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6
N text/x-markdown
U drh
W 1499
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](/timeline?c=94bb313444b0165e)
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.
Z 0f78c437a1f517acdf22a8bad6012f73