I have an similar problem, already commented in app rating. For the discussion here, see D678187429.
It's related to all PDF files, and there should be enough space on the internal iPad storage. I have to admit that I use a university webDAV, which can be access by the desktop app (Linux), but there requires a server verification in the settings from time to time. So it might be something due to an odd setting up of the webDAV API.
(+0000752): HTTP GET https://[…]/[…]/zotero/M34G8QLJ.zip failed with 401
Your WebDAV server is returning an HTTP 401 Unauthorized error, with no WWW-Authenticate header to trigger Basic Authentication (which might have already happened, but then the 401 would still be incorrect). You'll need to talk to your IT department.
But the point is that the previous **verification** in the iOS app is successful, and logging in with the desktop app is also possible with the same credentials. I checked that several times. Not to mention the webDAV connection with my file explorer, which runs smoothly.
So I am not really understanding why the webDAV connection seems to be handled differently when downloading a PDF in the iOS app. I do not understand the error 401 just in that scenario. For me it looks as if the webDAV connection is implemented in a different way only for the PDF download.
But I understand that it was not correct from my side to point to that behaviour via the app review. I apologize for that.
It's returning a 401 Unauthorized error and not including the required WWW-Authenticate header that triggers authentication in HTTP clients. There's nothing for the app to do in that situation other than show an error. This is just how HTTP authentication works. From RFC 9110:
The server generating a 401 response MUST send a WWW-Authenticate header field (Section 11.6.1) containing at least one challenge applicable to the target resource.
The lack of the required header can easily be seen in a curl request to the ZIP file:
You said yourself that you sometimes have to return to the prefs and reverify the server in the desktop app. That would never be necessary for a properly functioning WebDAV server, and this is the reason.
Again, you'll need to talk to your IT department, and they'll need to ask the vendor that provides their custom WebDAV server to fix it to follow HTTP specs.
Upgrade Storage
I have an similar problem, already commented in app rating. For the discussion here, see D678187429.
It's related to all PDF files, and there should be enough space on the internal iPad storage. I have to admit that I use a university webDAV, which can be access by the desktop app (Linux), but there requires a server verification in the settings from time to time. So it might be something due to an odd setting up of the webDAV API.
WWW-Authenticateheader to trigger Basic Authentication (which might have already happened, but then the 401 would still be incorrect). You'll need to talk to your IT department.I understand your objection.
But the point is that the previous **verification** in the iOS app is successful, and logging in with the desktop app is also possible with the same credentials. I checked that several times. Not to mention the webDAV connection with my file explorer, which runs smoothly.
So I am not really understanding why the webDAV connection seems to be handled differently when downloading a PDF in the iOS app. I do not understand the error 401 just in that scenario. For me it looks as if the webDAV connection is implemented in a different way only for the PDF download.
But I understand that it was not correct from my side to point to that behaviour via the app review. I apologize for that.
Best!
It's returning a 401 Unauthorized error and not including the required
WWW-Authenticateheader that triggers authentication in HTTP clients. There's nothing for the app to do in that situation other than show an error. This is just how HTTP authentication works. From RFC 9110: The lack of the required header can easily be seen in a curl request to the ZIP file: You said yourself that you sometimes have to return to the prefs and reverify the server in the desktop app. That would never be necessary for a properly functioning WebDAV server, and this is the reason.Again, you'll need to talk to your IT department, and they'll need to ask the vendor that provides their custom WebDAV server to fix it to follow HTTP specs.
Thanks for the detailed answer and your patience. I'll pass that to the responsible contact. As far as I know it's something bought.
Best!