today I stumbled again over a not that easy to find error: A customer complained that he was not able to sync a library to his local drive; the sync starts but then the clients shows that a few percent of the file list were received and starts over in an infinite loop.
This happens when the Server-URL in the client is specified to use an unencrypted connection vie HTTP and the Seafile server automatically redirects all HTTP request to HTTPS.
The error would be easy to spot if the client would immediately complain about the redirect, but it’s possible to authenticate, only the synchronization of libraries fails.
If the client notices a redirect it should display a message like
»The Seafile Server [SERVERNAME] wants to use an encrypted connection, it not possible to sync libraries until you agree to enable encryption. Shall encryption (HTTPS) be enabled?«
and offer to change the server URI automatically.
An alternatively and even better solution would be to make the client honor redirects when syncing libraries, too.
Strange. I tested that with my server and it just gives an error that it cannot sync. To my mind that’s an organizational issue which should not be technically solved.
not sure, but IMHO it’s a good practice to redirect all HTTP request to HTTPS automatically instead of showing an 404 page like this:
return 301 https://$host$request_uri;
It’s at least convenient for users, which is a valid requirement by itself.
Technically it does excactly the same as HSTS but only on the server side and for first time connections. The Seafile client don’t have to honor redirects, but it should handle redirects in a consistent way. If redirects prevent syncing libraries, authentication should also fail.
Showing a message and offer to modify the URI is only necessary if the client have to handle authentications and synchronization differently.
All our deployments of seafile server have this exact configuration block for plain http requests. This works flawless with browsers and client alike.
To me, this sounds more like a typo in either seahub_settings.py or ccnet.conf file, like a missing “s” in “https://server-url/”
That would mean, that for every request that is sent to seafile, the webserver would redirect it to https, then forward it to seafile, which in turn would rewrite it to http, causing the client to re-evaluate the new http adress, which in turn would be altered by the web server… you get the point.
I’d go for checking the config files first.
Never had any infinit loops on any machines we’ve set up… Would be very interested to help though, if it’s not a typo.
thanks for your kind offer.
I checked the configuration files twice, everything is set to https. (BTW: It was a good opportunity to use a look ahead regular expression again: grep -Pi ‘http(?!s)’ conf/* )
But if you don’t suffer from this bug, something else has to be different. Do you use a rewrite instead of an explicit return statement?
I made a stupid mistake here. On a “normal” website deployment we would use a 301. But for seafile we dont.
Here is, how we rewrite the address in case of http requests:
rewrite ^ https://$http_host$request_uri? permanent;
I just tested with my own seafile instance at home (6.0.5 pro). If I change the server address to http instead of https, then change a file in a library, the file will be indexed, but the library state just changes from ‘commit’ to ‘error’.
Once I change back the address, and click the refresh button (upper right corner), the upload works like expected again.
No infinit loops, whatsoever…
Sorry for the confusion.
A rewrite from
https just can’t happen on the server side only - it always requires interaction with the HTTP client - since it needs to connect to a different port and perform the TLS handshake and so on.
So it should not make a difference whether you use
return 301 ... - both cases would generate a HTTP response with a code of 301/302 and the HTTPS url in the
Sure. I didn’t say it does not. I just pointed out, that we do not use a 301 statement.
Aren’t we about to find out, what the differences are?
Do you use Shibboleth for authentication? I will check, if the redirection to and from the IdP could be responsible.
Yes, of course! Sorry if I sounded a bit too harsh.
I just wanted to point out that
return 301 ... will do the exact same thing as
rewrite ... permanent, so it should not make a difference. I see now that maybe I should have directed my comment directly at @scheff.
May I too should use smilies to give it a hint of a tone…
We do not use Shibboleth. Just plain old LDAP. Which is fairly enough for the standards our customers ask for.
Maybe you can better debug the roundtrips of your connections with wireshark or charles proxy?
Sounds interesting enough to dig a bit deeper on it…