Empty Response
Closed this issue ยท 27 comments
Hi,
I tried your plugin because it fits perfectly my need. But When I enter the URL and User / Pass the server only returns an empty response.
When I add the Data to the Calender App on my Mac, it finds all the Calenders.
Is it possible, that I need to add something to the url (the correct path for the calenders or something)? If so, how to find this path?
Hope you can help me.
@Ruko2010 : sorry for the late answer, this is due to there is no notification if someone opens a new issue ๐ .
so, have you already enabled logging in the plugin settings ?
if yes, can you post the content of the logfile here ?
additionally: what brand is your caldav server ?
@wernerjoss Yes I enabled logging. Here is the output:
CalendarURL:https://caldav.marketcircle.net/
using temp file: /tmp/result.txt for Server Response
Lines processed: 0
WARNING: no valid Ical Data found in Server Response !
The Server is from the Mac-Programm Daylite, an CRM Tool.
When I go to the URL for the Calenders (https://caldav.marketcircle.net/) and enter my Userdata the following Page is shown:
My Guess was, that I need to go to a "deeper" URL for the Calendar, but I don't know which one.
When I open the Calendar on my Mac, the URL is like this:
But entering this in the URL Field in your Plugin is also not working.
Calling the URL (https://caldav.marketcircle.net/principals/3000/) in the Browser does also not work. It just shows a blank page.
Hope you can help me.
ok, this puts some light on this issue ๐ - the main URL seems to be protected with .htaccess,
so will already have to be authenticated to get past this to https://caldav.marketcircle.net/principals/3000/.
The Plugin needs the principal URL to retrieve Calendar data, but cannot not get there as it does not authenticate itself via .htaccess.
You could try to provide the .htaccess credentials directly in the principal URL: https://username:password@caldav.marketcircle.net/principals/3000/ .
I'm not sure if this will work as I never tried.
you might get an Error like 'invalid' URL in the Plugin Settings page...
ok, my proposal was a wild guess, I admit ๐ .
and no, the plugin does not use plain curl, but WP http request methods (which uses curl internally) as using curl directly violates the WP programming standards.
probably best advice to troubleshoot this issue is to fiddle with curl cli,
see also the corresponding WP Support Page
Btw, what should be the "correct" response? An XML layout with the calendar?
yes, that looks like the URL is not correct - if it is, you will get your calendar data as text stream, surrounded with some xml tags.
can't you figure out what URL your Mac Calendar uses ?
additional note: probably the Mac Calendar uses some PROPFIND requests to determine the complete URL - these are not (yet) implemented in my plugin, but you could use this also with curl to find out...
maybe this https://wiki.wocommunity.org/display/~probert/CalDAV+and+CardDAV+handshake can help ?
(note the .well-known part of the URL to request...)
Ok, this was really helpful. I'm not sure how, but I got the URLs of the ICS-Files of the Calendars with this call:
curl --request PROPFIND --insecure --basic --user MY_USER:MY_PASSWORD --header "Content-Type: text/xml" --header "Brief:t" --header "Depth: 1" --data "<D:propfind xmlns:D='DAV:'><D:prop><D:displayname/></D:prop></D:propfind>" https://caldav.marketcircle.net/calendars/3000/calendar_category_no_category/
this results in this output:
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/</D:href>
<D:propstat>
<D:prop>
<D:displayname>No Category</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/F3524EAF-C7FA-4074-A3B4-ED04353B9FC7.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>F3524EAF-C7FA-4074-A3B4-ED04353B9FC7.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/5550632A-2552-4C3C-8AA9-8934911847EF.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>5550632A-2552-4C3C-8AA9-8934911847EF.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/FE1360DE-428F-4C08-855A-4C85EFFD3580.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>FE1360DE-428F-4C08-855A-4C85EFFD3580.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/1823F46D-13BF-4804-90D3-5F1A25A21FBA.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>1823F46D-13BF-4804-90D3-5F1A25A21FBA.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/2AEE10A3-2720-404F-B8A7-7AB78D34F854.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>2AEE10A3-2720-404F-B8A7-7AB78D34F854.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/247167C5-6DD6-4D63-BA1A-6221DF585979.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>247167C5-6DD6-4D63-BA1A-6221DF585979.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/65492822-1F82-40EF-A7DE-9851FB069174.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>65492822-1F82-40EF-A7DE-9851FB069174.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/7C5AEF6A-0276-4F77-A6C5-D5B470C8E81D.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>7C5AEF6A-0276-4F77-A6C5-D5B470C8E81D.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/F75B4300-E44B-4757-A05E-2A8525A31AF4.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>F75B4300-E44B-4757-A05E-2A8525A31AF4.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/D763EF36-90B7-4C02-9C21-AD2D5F9C0402.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>D763EF36-90B7-4C02-9C21-AD2D5F9C0402.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/D6868A60-FDEA-4479-A842-6A0D36408E4D.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>D6868A60-FDEA-4479-A842-6A0D36408E4D.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/calendars/3000/calendar_category_no_category/3577DF9C-DDCC-4A72-B3B3-13C9F137478B.ics</D:href>
<D:propstat>
<D:prop>
<D:displayname>3577DF9C-DDCC-4A72-B3B3-13C9F137478B.ics</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
If I enter the URL in the Browser https://caldav.marketcircle.net/calendars/3000/calendar_category_no_category/F3524EAF-C7FA-4074-A3B4-ED04353B9FC7.ics
it downloads an ICS-File.
If I make a wget call to https://*username*:*password*@caldav.marketcircle.net/calendars/3000/calendar_category_no_category/F3524EAF-C7FA-4074-A3B4-ED04353B9FC7.ics
it also downloads the file.
But in this ics-Files, there is always only 1 Entry ๐ฉ.
So I think the full URL for one calendar should be https://caldav.marketcircle.net/calendars/3000/calendar_category_3000/
. But Entering this (or https://USERNAME:PASSWORD@caldav.marketcircle.net/calendars/3000/calendar_category_3000/
) will also result in the following Log:
Log created on 20:07:13 11:35:41
CalendarURL:https://caldav.marketcircle.net/calendars/3000/calendar_category_3000/
using temp file: /tmp/result.txt for Server Response
Lines processed: 0
WARNING: no valid Ical Data found in Server Response !
ok, so you managed to get a list with URLs to .ics files, with each of them holds exactly 1 Event in the form:
`BEGIN:VEVENT
DTSTART:...
END:VEVENT`
-right ?
if so, you are not far away from success ๐
but still, the Calendar URL https://caldav.marketcircle.net/calendars/3000/calendar_category_3000/ is not the correct one for the request REPORT (which is used in the plugin).
a REPORT request to the correct URL will not generate a list of individual .ics files but a list of Events from the Calendar, basically the content of all the above .ics files in one stream.
ok, so you managed to get a list with URLs to .ics files, with each of them holds exactly 1 Event in the form:
`BEGIN:VEVENT
DTSTART:...
END:VEVENT`
-right ?
yes
if so, you are not far away from success ๐
but still, the Calendar URL https://caldav.marketcircle.net/calendars/3000/calendar_category_3000/ is not the correct one for the request REPORT (which is used in the plugin).
a REPORT request to the correct URL will not generate a list of individual .ics files but a list of Events from the Calendar, basically the content of all the above .ics files in one stream.
Do you know how the body of the REPORT Request should look like? So I have something to test for my curl requests?
you can take a look at this simple pure php project which does exactly the same thing as the WP Plugin with plain curl.
Thanks for your help, but I think I will give up. I'll always only get an Empty response. No type of error or something.
well, figuring out the correct caldav URL for calendars is not always easy, I know.
and that's why systems like owncloud or nextcloud provide a link to this URL in their backend.
marketcircle.net should do the same, IMHO.
if not, just ask them - they certainly know their calendar naming scheme ๐
Sadly, I have contacted them before, but they were unable to help. Maybe just a "no techi"-support. They just referred my to this site, which is not quite helpful:
https://support.marketcircle.com/hc/en-us/articles/360036654413-Sharing-your-Daylite-calendar-and-tasks-outside-of-Daylite%3E%E2%80%9D#Cloud_Sharing:_Other_Applications
I think they assume, that the external program is capable of doing the propfind itself and "knows" how to find the correct calendar url, like Calendar on Mac where it is working.
that is bad support, yes ๐
anyways, there should be a way to find out - can you try this ?
I just checked it out and it finds correctly the URLs of all my calendars on my owncloud server, so I think it should also work for you.
I have just modified it a bit by adding the lines:
echo "dav_user_path: $dav_user_path"
echo "dav_user_calendar_home_path: $dav_user_calendar_home_path"
echo "dav_user_calendar_paths: $dav_user_calendar_paths"
after the # Get calendar paths section and omitted all the rest.
of course you will need to adapt the server and credentials section.
the script itself is for linux bash, it also needs xmlstarlet installed, a cli xml utility program.
all this should also be available on Mac, using homebrew, I think.
Ok, I'll give it a shot this afternoon, thanks for your help!
ok, you can find the adapted script at my gists.
good luck ๐
It also does not work :/. I just get this output:
xmlXPathCompiledEval: evaluation failed
runtime error: element with-param
Failed to evaluate the expression of variable 'select'.
Undefined namespace prefix
xmlXPathCompiledEval: evaluation failed
runtime error: element with-param
Failed to evaluate the expression of variable 'select'.
Undefined namespace prefix
xmlXPathCompiledEval: evaluation failed
runtime error: element for-each
Failed to evaluate the 'select' expression.
dav_user_path:
dav_user_calendar_home_path:
dav_user_calendar_paths:
well, then, I guess I'm out of ideas...
what is your version of xmlstarlet/libxml2/libxslt ?
`cirrus:~$ xmlstarlet --version
1.6.1
compiled against libxml2 2.9.4, linked with 20904
compiled against libxslt 1.1.29, linked with 10132`
I tried it on another server with xmlstarlet version 1.6.1 with the same result.
so, version dependency is also not the problem.
that leaves me with no other idea.
the real problem ist that each incarnation of caldav server uses its own naming scheme for user's calendars, and, even worse, the detection is also not standardized.
and while the most common brands (baikal, owncloud, nextcloud, mailbox.org...) have some docs around or even provide direct links in their backends, yours does obviously none of this.
I'm closing this now as there does not seem to be any comprehensive solution.
nevertheless thank you for your effort!
you're welcome - I wish we could have solved this, but ATM, I see no way.