-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to connect : #158
Comments
I've never seen such problems before - this is the requests library, breaking while reading the response from the server. So it doesn't have anything to do with the caldav library, per se. I've tried googling a bit, the only thing I found on that error message was https://stackoverflow.com/questions/68584385/invalid-chunk-length-pull-zip-file-from-url-to-python ... weird :-( You can try in C:\ProgramData\Anaconda3\lib\site-packages\caldav\objects.py just before line 155 to add I did run the caldav test suite towards NextCloud at https://e.email, and I did succed with that. |
I get an error on the print command:
Would you like me to create you an account on my NC server? |
Still not working with 0.8.1 |
Yes please, I would love to run tests towards it. I've tested NextCloud at try.nextcloud.com and tests passes (except that sync-tokens and expandation of recurring events/todos doesn't work). I tried nextcloud at e.email / cloud.global, and got the same results a couple of weeks ago, but arbitrary errors when I tried some few days ago. Here are a couple of suggestions on how to set a password:
You may eventually send credentials by email, i.e. [email protected] |
... or just use the NextCloud functionality for setting a new password, great :-) |
I also get those InvalidChunkLength when running the tests. Very weird indeed. Could it have something to do with tcp segment size possibly? I will do research into this, but cannot promise any timeline. |
Unfortunately so far I can only report .... "I understand nothing". I can most likely create some workaround for this problem, but it would be better to understand what's going on. So I will do more research. >>> sys.path.insert(0, '.') ; import caldav ; from tests.conf import client
>>> c=client()
>>> c.principal()
Traceback (most recent call last):
(...)
urllib3.exceptions.InvalidChunkLength: InvalidChunkLength(got length b'', 0 bytes read)
>>> c.principal()
Traceback (most recent call last):
(...)
urllib3.exceptions.InvalidChunkLength: InvalidChunkLength(got length b'', 0 bytes read)
>>> c.propfind(c.url)
<caldav.davclient.DAVResponse object at 0x7f32aade2970>
>>> _.raw
b'<?xml version="1.0"?>\n<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns"><d:response><d:href>/remote.php/dav/</d:href><d:propstat><d:prop><d:resourcetype><d:collection/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response></d:multistatus>\n'
>>> c.principal()
Principal(https://cloud.xxx.fr/remote.php/dav/principals/users/tobixen/) |
Ok, I'm a bit smarter now. There are two different ways of doing authentication over http, it's "digest" and "basic auth". The current code attempts to do a digest first, and if it fails with a 401, it falls back to basic auth. This caldav server gives a 401 when doing i.e. a PROPFIND with the digest method and an empty body, but it throws some spectacular error when doing a PROPFIND with a body and the digest method. There exists a workaround that works right now, the DAVClient class may take an auth object: >>> sys.path.insert(0, '.') ; import caldav ; from tests.conf import client ; c=client()
>>> import requests
>>> c = caldav.DAVClient(url=c.url, auth=requests.auth.HTTPBasicAuth(c.username, c.password))
>>> c.principal()
Principal(https://cloud.xxxx.fr/remote.php/dav/principals/users/tobixen/) I still believe this is more a server error than a client error, but I will read up a bit on the http standard to see if there are any better methods to discover weather the server expects digest or basic auth. |
When doing a simple proppatch towards the caldav URL without any authentication information, it shows this:
The "basic" above indicates that "basic auth" should be used rather than "digest". Perhaps the server is terminating the connection before the request is completed when a body is sent rogether with the wrong auth type. I find it strange that the "elegant and simple HTTP library for Python, built for human beings" can't accept a simple username and password and choose one auth over the other by itself - but anyway, I will build proper auth type discovery into the library, hopefully this will solve the issue with this server (and perhaps it will solve other weird issues as well). While I'm at it, maybe I'll have a stab at #119 |
It is working using 0.8.2. Thanks |
One more thing perhaps, Can you hide the NC url in your outputs above? |
Sorry, I was a bit uncertain if that was a public URL or not |
No problem, thanks for the fix! |
Since the previous code worked OK with other nextcloud instances, I think the real culprit here was in a layer above nextcloud (apache or nginx setup). Now that I'm trying to clean away the old code, radicale breaks. It has sort of the opposite behaviour. Without the body and no auth given, it will give a 207 instead of a 401. |
When I tried to connect to my nextcloud server on an OVH Web Host, I get the following error:
This calendar is correctly set up on thunderbird or DavX5.
Any idea? Is it my server configuration? or OVH?
The text was updated successfully, but these errors were encountered: