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 "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](/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