AgenDAV 2.0.0 doesn’t show events from SabreDAV 3.2 Server #191

tealord · 2016-11-28T14:46:31Z

Hello,

like @yreveill mentioned in #177 there is an issue with agendav-2.0.0 and sabredav 3.2

AgenDAV lists all the correct calendars but not the events:
Interface error
Error loading events from calendar /calendarserver.php/calendars/foo/4cb0d1e9-0223-41a7-9040-6f9eff9826b5/

Apache24 Log (SabreDav vhost):

$IP - - [$DATE] "REPORT /calendarserver.php/calendars/foo/4cb0d1e9-0223-41a7-9040-6f9eff9826b5/ HTTP/1.1" 500 275

AgenDAV Log:

[2016-11-28 15:31:14] agendav.WARNING: Received unexpected HTTP code 500 (Server error: REPORT http://myserver.com/calendarserver.php/calendars/foo/4cb0d1e9-0223-41a7-9040-6f9eff9826b5/ resulted in a 500 Internal Server Error response: (truncated...) ) for input: Symfony\Component\HttpFoundation\ParameterBag::__set_state(array( 'parameters' => array ( 'calendar' => '/calendarserver.php/calendars/foo/4cb0d1e9-0223-41a7-9040-6f9eff9826b5/', 'start' => '2016-10-30', 'end' => '2016-12-11', 'timezone' => 'Europe/Berlin', '_' => '1480341200251', ), )) [] []
[2016-11-28 15:31:14] agendav.INFO: < 500 [] []

It seems that SabreDAV doesn’t like the REPORT method since I get valid output using GET for -X in the following:

% curl -X REPORT --digest --user foo:foo -o - http://myserver.com/calendarserver.php/calendars/foo/4cb0d1e9-0223-41a7-9040-6f9eff9826b5/

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:sabredav-version>3.2.0</s:sabredav-version>
<s:exception>ErrorException</s:exception>
<s:message>XMLReader::XML(): Empty string supplied as input</s:message>
</d:error>

Thankful for any help!

The text was updated successfully, but these errors were encountered:

evert · 2016-11-29T03:34:49Z

If you do a curl request with REPORT on the command line, you need to supply a correct request body. This is why it's complaining about an empty string.

jorgelzpz · 2016-12-07T18:36:19Z

@evert after some testing, I have seen that cURL always sends the first request with Content-Length: 0 when digest authentication is used, even when a body is specified. I think it does that to save some bandwidth until digest parameters are negotiated.

AgenDAV uses Guzzle, which internally uses cURL, so uses the same approach.

I don't know if the standard requires the first request to be fully sent (haven't been able to find anything on this topic), but this was not an issue with older SabreDAV releases. SabreDAV 3.2.0 returns a 500 error on REPORT requests with no body.

Sample PROPFIND request that works:

% curl --digest --user admin -X PROPFIND \
 -H "Content-Type: application/xml" --data @propfind.xml \
 http://localhost:8082/calendarserver.php/ -v
Enter host password for user 'admin':
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8082 (#0)
* Server auth using Digest with user 'admin'
> PROPFIND /calendarserver.php/ HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/xml
> Content-Length: 0
>
< HTTP/1.1 401 Unauthorized
< Date: Wed, 07 Dec 2016 18:21:34 GMT
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.6.24-1+deb.sury.org~trusty+1
< X-Sabre-Version: 3.2.0
< WWW-Authenticate: Digest realm="SabreDAV",qop="auth",nonce="5848532ee79e4",opaque="df58bdff8cf60599c939187d0b5c54de"
< Content-Length: 403
< Content-Type: application/xml; charset=utf-8
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:8082/calendarserver.php/'
* Found bundle for host localhost: 0x7f8251c0f210
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 8082 (#0)
* Server auth using Digest with user 'admin'
> PROPFIND /calendarserver.php/ HTTP/1.1
> Host: localhost:8082
> Authorization: Digest username="admin", realm="SabreDAV", nonce="5848532ee79e4", uri="/calendarserver.php/", cnonce="MDk3ODI0YjUwNTZkMGNiZDMwYTY4YzU3NDJiNDk3NGM=", nc=00000001, qop=auth, response="f40755e5078d0fd578a3d813ab205261", opaque="df58bdff8cf60599c939187d0b5c54de"
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/xml
> Content-Length: 347
>
* upload completely sent off: 347 out of 347 bytes
< HTTP/1.1 207 Multi-Status
< Date: Wed, 07 Dec 2016 18:21:34 GMT
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.6.24-1+deb.sury.org~trusty+1
< X-Sabre-Version: 3.2.0
< Vary: Brief,Prefer
< DAV: 1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, calendar-access, calendar-proxy, calendarserver-subscribed, calendar-auto-schedule, calendar-availability, resource-sharing, calendarserver-sharing
< Content-Length: 1824
< Content-Type: application/xml; charset=utf-8
<
<?xml version="1.0"?>
[...]

Sample REPORT request that doesn't work:

% curl --digest --user admin -v -X REPORT \
  -H "Content-Type: application/xml" --data @report.xml \
  http://localhost:8082/calendarserver.php/calendars/admin/micalendario/ -v
Enter host password for user 'admin':
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8082 (#0)
* Server auth using Digest with user 'admin'
> REPORT /calendarserver.php/calendars/admin/micalendario/ HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/xml
> Content-Length: 0
>
< HTTP/1.1 500 Internal Server Error
< Date: Wed, 07 Dec 2016 18:25:29 GMT
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.6.24-1+deb.sury.org~trusty+1
< X-Sabre-Version: 3.2.0
< Content-Length: 275
< Connection: close
< Content-Type: application/xml; charset=utf-8
<
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>3.2.0</s:sabredav-version>
  <s:exception>ErrorException</s:exception>
  <s:message>XMLReader::XML(): Empty string supplied as input</s:message>
</d:error>
* Closing connection 0

@evert do you think this can be considered as a SabreDAV issue?

logic · 2017-01-05T04:51:10Z

FWIW, I "fixed" this with a local patch to the vendored version of guzzle:

--- agendav-2.0.0/web/vendor/guzzlehttp/guzzle/src/Client.php.orig	2017-01-05 04:45:53.426094472 +0000
+++ agendav-2.0.0/web/vendor/guzzlehttp/guzzle/src/Client.php	2017-01-05 04:45:08.806092753 +0000
@@ -347,7 +347,7 @@
                     break;
                 case 'digest':
                     // @todo: Do not rely on curl
-                    $options['curl'][CURLOPT_HTTPAUTH] = CURLAUTH_DIGEST;
+                    $options['curl'][CURLOPT_HTTPAUTH] = CURLAUTH_ANY;
 		    $options['curl'][CURLOPT_USERPWD] = "$value[0]:$value[1]";
                     break;
             }

I leave it to others to decide what the correct thing to do here actually is. 😄

Inspired by:

evert · 2017-01-08T22:43:22Z

This sounds like a bug to me, frankly. Might be worth opening a ticket somewhere.

jorgelzpz · 2017-01-16T19:02:41Z

Finally found some time to file an issue: fruux/sabre-dav#932

ondrejvrabel · 2018-01-01T17:31:33Z

@logic you saved the day - it solved the problem

deutrino · 2019-07-11T00:08:31Z

This bug also renders AgenDAV useless with Baikal. The workaround at #191 (comment) fixes it.

welly2103 · 2019-12-06T11:39:07Z

Thank you! #191 (comment)

This error still shows up with this setup:

AgenDAV 2.2.0
Baikal 0.6.1

Just changed the $options['curl'][CURLOPT_HTTPAUTH] to CURLAUTH_ANY and everything works as expected, thank you.

deutrino · 2019-12-10T22:11:19Z

Suggest editing the title to reflect that this affects multiple clients.

lightmaster · 2023-02-24T02:59:14Z

I just ran into this now with AgenDAV 2.6.0 and Baikal 0.9.3. The "fix" by logic still works.

#191 (comment)

FWIW, I "fixed" this with a local patch to the vendored version of guzzle:

--- agendav-2.0.0/web/vendor/guzzlehttp/guzzle/src/Client.php.orig	2017-01-05 04:45:53.426094472 +0000
+++ agendav-2.0.0/web/vendor/guzzlehttp/guzzle/src/Client.php	2017-01-05 04:45:08.806092753 +0000
@@ -347,7 +347,7 @@
                     break;
                 case 'digest':
                     // @todo: Do not rely on curl
-                    $options['curl'][CURLOPT_HTTPAUTH] = CURLAUTH_DIGEST;
+                    $options['curl'][CURLOPT_HTTPAUTH] = CURLAUTH_ANY;
 		    $options['curl'][CURLOPT_USERPWD] = "$value[0]:$value[1]";
                     break;
             }

KiralyCraft · 2023-09-13T17:56:45Z

This still seems to be correct, I can also confirm functionality with the "fix".

kidk mentioned this issue May 6, 2018

feat: CardDAV support monicahq/monica#1284

Merged

4 tasks

FroggyJuul mentioned this issue Jul 29, 2018

AgenDav with SabreDav agendav.CRITICAL #249

Closed

intelli-xlcode mentioned this issue Jan 30, 2020

:XML(): Empty string supplied as input when trying to sync changes from the WebDAV server mstilkerich/rcmcarddav#209

Closed

pixelbrackets added bug critical help-wanted labels Apr 28, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AgenDAV 2.0.0 doesn’t show events from SabreDAV 3.2 Server #191

AgenDAV 2.0.0 doesn’t show events from SabreDAV 3.2 Server #191

tealord commented Nov 28, 2016

evert commented Nov 29, 2016

jorgelzpz commented Dec 7, 2016

logic commented Jan 5, 2017

evert commented Jan 8, 2017

jorgelzpz commented Jan 16, 2017

ondrejvrabel commented Jan 1, 2018

deutrino commented Jul 11, 2019

welly2103 commented Dec 6, 2019

deutrino commented Dec 10, 2019

lightmaster commented Feb 24, 2023

KiralyCraft commented Sep 13, 2023

AgenDAV 2.0.0 doesn’t show events from SabreDAV 3.2 Server #191

AgenDAV 2.0.0 doesn’t show events from SabreDAV 3.2 Server #191

Comments

tealord commented Nov 28, 2016

evert commented Nov 29, 2016

jorgelzpz commented Dec 7, 2016

logic commented Jan 5, 2017

evert commented Jan 8, 2017

jorgelzpz commented Jan 16, 2017

ondrejvrabel commented Jan 1, 2018

deutrino commented Jul 11, 2019

welly2103 commented Dec 6, 2019

deutrino commented Dec 10, 2019

lightmaster commented Feb 24, 2023

KiralyCraft commented Sep 13, 2023