I want to write a little LDAP 2 CardDav Gateway, which gets a request (from a Desktop Phone/PBX) on it's LDAP side and converts it to a CardDAV request.
So for I used raw HTTP/XML requests and was able to:
Query the base directory /kdav/addressbooks/ with PROPFIND and depth: 1
for results with <d:resourcetype><d:collection> repeat the query recursivly
for results with <d:resourcetype><card:addressbook> add them to the addressbook list
after the recursion is done a REPORT query with <card:addressbook-query><card:address-data><card:prop name="TEL"><card:prop name="N"></card:address-data> over the addreesbook list
Now this gives me currently the possibility to get all contacts and create a phonebook.xml, which can be fetched by my phones.
Unfortunatly I was unable to restrict the PROPFIND to only return results of <d:resourcetype><d:collection> or <d:resourcetype><card:addressbook>. This is problematic, as I can have nested addressbooks, which return all children on PROPFIND, in the worst case this means I query an addressbook, which has no nested address books, but 500 contacts, so I get 500 results back which I completely filter out on client side.
Any ideas on how to solve that more efficient?
Also here is an example of a response I currently get, which makes me assume that the addressbooks are nested. The server is Kopano and either I'm misinterpreting nested address books or it breaks the specification.
<?xml version="1.0"?>
<d:multistatus
xmlns:d="DAV:"
xmlns:s="http://sabredav.org/ns"
xmlns:card="urn:ietf:params:xml:ns:carddav"
xmlns:cal="urn:ietf:params:xml:ns:caldav"
xmlns:cs="http://calendarserver.org/ns/">
<d:response>
<d:href>/kdav/addressbooks/public/</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:response>
<d:href>/kdav/addressbooks/public/sdfsf/</d:href>
<d:propstat>
<d:prop>
<d:resourcetype>
<d:collection/>
<card:addressbook/>
</d:resourcetype>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>/kdav/addressbooks/public/Test/</d:href>
<d:propstat>
<d:prop>
<d:resourcetype>
<d:collection/>
<card:addressbook/>
</d:resourcetype>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
</d:multistatus>
Related
While playing with Google Calendar and CalDav i realized that if for a given event you modify a notification (Alarm), the event's ETag won't change.
Now, comparing ETags is essential to find out when a given event changes (in CalDav).
The request i am using to find out the ETag is
<?xml version=\"1.0\" encoding=\"utf-8\"?><d:propfind xmlns:d=\"DAV:\" xmlns:cs=\"http://calendarserver.org/ns/\"><d:prop><d:getetag /></d:prop></d:propfind>
Which would return something like
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:caldav="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:ical="http://apple.com/ns/ical/">
<D:response xmlns:carddav="urn:ietf:params:xml:ns:carddav" xmlns:cm="http://cal.me.com/_namespace/" xmlns:md="urn:mobileme:davservices">
<D:href>/caldav/v2/myemail#gmail.com/events/</D:href>
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:carddav="urn:ietf:params:xml:ns:carddav" xmlns:cm="http://cal.me.com/_namespace/" xmlns:md="urn:mobileme:davservices">
<D:href>/caldav/v2/myemail%40gmail.com/events/xqrjsgs1gj35cpub2nnumntm5j%40google.com.ics</D:href>
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:getetag>"63723144835"</D:getetag>
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>
Now, after you go and modify the notification of that event in Google Calendar you still keep getting the same ETag:
<D:getetag>"63723144835"</D:getetag>
Is there anything else i might look for in order to find out when a notification/Alarm changes in an event? or, am i doing anything wrong?
This definitely sounds like a bug/protocol violation on the Google CalDAV implementation side:
CalDAV specifies that servers should use strong tags: https://www.rfc-editor.org/rfc/rfc4791#section-5.3.4
Strong etags correspond pretty much to bit to bit comparison: https://www.rfc-editor.org/rfc/rfc2616#section-13.3.3
Even if there were good reasons for returning a weak etag, what you get back (e.g. "63723144835") does not correspond to a weak etag syntax. Should look like "W/63723144835" (see https://www.rfc-editor.org/rfc/rfc2616#section-3.11 )
With all that said, you should really consider using WebDAV Sync ( https://www.rfc-editor.org/rfc/rfc6578 ) to monitor changes in a given calendar collection. I would be very surprised if the Google Calendar Server exposed the same issue when using sync.
At this documentation at page 15 of 22 it gives example:
<EnhancedAirBookRQ xmlns="http://services.sabre.com/sp/eab/v3_2">
<OTA_AirBookRQ>
<HaltOnStatus Code="NN"/>
<OriginDestinationInformation>
<FlightSegment DepartureDateTime="2014-06-03T12:30:00" FlightNumber="1022" NumberInParty="1" ResBookDesigCode="F" Status="NN">
<DestinationLocation LocationCode="LAS"/>
<MarketingAirline Code="AA" FlightNumber="1022"/>
<OriginLocation LocationCode="DFW"/>
</FlightSegment>
</OriginDestinationInformation>
<RedisplayReservation NumAttempts="2" WaitInterval="100"/>
</OTA_AirBookRQ>
</EnhancedAirBookRQ>
Could you help me understand if I set such parameters for NumAttempts and WaitInterval what I am missing.
I could guess that I will have quick answer for segments with no halt on status.
Inside the OTA_AirBook HaltOnStatus and RedisplayReservation work together. Basically, behind the scenes, the service will book what you requested and will attempt to redisplay the reservation up to NumAttempts times, waiting WaitInterval milliseconds between each check.
Each time it will look if the status of the segments in the itinerary changed, and it will validate them against what <HaltOnStatus Code="NN"/> has, (there can be several <HaltOnStatus Code="NN"/>). At least for NN it will keep on checking, for other ones like UC it will get out of the loop.
The reason is that NN is Sabre waiting for the airline's response on the booking request, and (I believe) anything else would be considered their response, so it leaves the loop.
I'm currently implementing a WebDAV server and am totally stuck at the PROPFIND method handling. Are there any resources out there with actual examples? I have a hard time following the specification, which is imo very vague. Here's e.g. a request "Litmus" sends my server:
<?xml version="1.0" encoding="UTF-8"?>
<a:propfind xmlns:a="DAV:" xmlns="DAV:">
<b:prop xmlns:b="DAV:">
<b:getcontentlength/>
<b:getlastmodified/>
<b:displayname/>
<b:resourcetype/>
<c:foo xmlns:c="http://example.com/neon/litmus/" xmlns="http://example.com/neon/litmus/"/>
<bar/>
</b:prop>
</a:propfind>
Apparently, my response to that is not okay, since Litmus says "4. propfind_d0........... FAIL (No responses returned)":
<?xml version="1.0" encoding="UTF-8"?>
<DAV:multistatus
xmlns:DAV="DAV:">
<DAV:response>
<DAV:href>/test/litmus/</DAV:href>
<DAV:propstat>
<DAV:prop>
<DAV:getlastmodified>Fri, 30 Sep 2016 23:28:31 +0000</DAV:getlastmodified>
<DAV:displayname>litmus</DAV:displayname>
<DAV:resourcetype>
<DAV:collection></DAV:collection>
</DAV:resourcetype>
</DAV:prop>
<DAV:status>HTTP/1.1 200 OK</DAV:status>
</DAV:propstat>
<DAV:propstat>
<DAV:prop>
<DAV:getcontentlength></DAV:getcontentlength>
<a:foo
xmlns:a="http://example.com/neon/litmus/">
</a:foo>
<a:bar></a:bar>
</DAV:prop>
<DAV:status>HTTP/1.1 404 Not Found</DAV:status>
</DAV:propstat>
</DAV:response>
</DAV:multistatus>
What would be a correct response, and how can I actually find out?
I have this annoying problem with the new Here Routing API 7.2:
If I want to use more than 2 waypoints (0 and 1) I get error as a responce from the server:
Request:
https://route.api.here.com/routing/7.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&waypoint2=55.9552%2C12.52421&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&app_code=XXXXXX&app_id=XXXXXXXXXX&routeattributes=wp,sm,sc,sh,bb,lg,no
ERROR RESPONSE:
<ns2:Error xmlns:ns2="http://www.navteq.com/lbsp/Routing-Errors/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="ApplicationError" subtype="NoRouteFound" xsi:type="ns2:RoutingServiceErrorType">
<Details>Error is NGEO_ERROR_INVALID_PARAMETERS</Details>
<AdditionalData key="error_code">NGEO_ERROR_INVALID_PARAMETERS</AdditionalData>
<MetaInfo>
<Timestamp>2016-02-18T15:30:21Z</Timestamp>
<MapVersion>8.30.61.154</MapVersion>
<ModuleVersion>7.2.66.0-1329</ModuleVersion>
<InterfaceVersion>2.6.21</InterfaceVersion>
</MetaInfo>
</ns2:Error>
If I take away the waypoin2 in above request it aswers ok:
Request:
https://route.api.here.com/routing/7.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&&app_code=XXXXXXXXXX&app_id=XXXXXXXXXX&routeattributes=wp,sm,sc,sh,bb,lg,no,legs
OK RESPONSE:
<rtcr:CalculateRoute xmlns:rtcr="http://www.navteq.com/lbsp/Routing-CalculateRoute/4">
<Response>
<MetaInfo>
<Timestamp>2016-02-18T13:38:57Z</Timestamp>
<MapVersion>8.30.61.153</MapVersion>
<ModuleVersion>7.2.65.0-1222</ModuleVersion>
<InterfaceVersion>2.6.20</InterfaceVersion>
</MetaInfo>
<Route>
<Waypoint>
<LinkId>-840260969</LinkId>
<MappedPosition>
<Latitude>55.6739539</Latitude>
<Longitude>12.4166495</Longitude>
</MappedPosition>
<OriginalPosition>
<Latitude>55.6739499</Latitude>
<Longitude>12.41686</Longitude>
</OriginalPosition>
<Type>stopOver</Type>
<Spot>0.5252525</Spot>
<SideOfStreet>left</SideOfStreet>
<MappedRoadName>Hvissingevej</MappedRoadName>
<Label>Hvissingevej</Label>
<ShapeIndex>0</ShapeIndex>
</Waypoint>
<Waypoint>...</Waypoint>
<Mode>...</Mode>
<Shape>...</Shape>
<BoundingBox>
<TopLeft>
<Latitude>55.6739539</Latitude>
<Longitude>12.4158812</Longitude>
</TopLeft>
<BottomRight>
<Latitude>55.6408489</Latitude>
<Longitude>12.5263282</Longitude>
</BottomRight>
</BoundingBox>
<Leg>...</Leg>
<Summary xmlns:rtc="http://www.navteq.com/lbsp/Routing-Common/4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="rtc:RouteSummaryType">
<Distance>11768</Distance>
<TrafficTime>951</TrafficTime>
<BaseTime>951</BaseTime>
<Flags>motorway</Flags>
<Flags>builtUpArea</Flags>
<Flags>park</Flags>
<Text>
..etc
Why does it not work with more that 2 waypoints???
This looks like a big fat bug to me, but I cant find anything about it on the here.com or anywhere on the internet... :((
THIS Request with 3 waypoints used to work in the old version 6.2:
http://route.nlp.nokia.com/routing/6.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&waypoint2=55.9552%2C12.52421&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&app_code=bSU31J0m--3cnUyNdSj4cw&app_id=dj92lxIBAWPAwMtNxCgm&routeattributes=wp,sm,sc,sh,bb,lg,no
OK RESPONSE:
<rtcr:CalculateRoute xmlns:rtcr="http://www.navteq.com/lbsp/Routing-CalculateRoute/4">
<Response>
<MetaInfo>...</MetaInfo>
<Route>
<RouteId>
REM8tfQAAAHRkVz-Q9ZLQGgFhqxu1ShAAAAAYETWS0AAAADAUtUoQAAAAAAAAPB_AAAAAAAA8H-XourNKMKGp1dKLwEVoKaWrTWkAAEAAABcSi8BAQAAAOk1pAABAAAAAADA_wEAAAAAAMD_ZSl--Cc6kst_SH8JSB2PGaiMIQUIAAAAlEh_CQgAAABwhiEFCAAAAAAAAP4PAAAAAAAA_s9seQ_mg7mwYJAXWCYYxLg-_P8yOgx7Z_zGqIBBluHNBoM
</RouteId>
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
<Mode>
<Type>fastest</Type>
<TransportModes>car</TransportModes>
<TrafficMode>disabled</TrafficMode>
<Feature weight="-1">boatFerry</Feature>
</Mode>
<Shape>...</Shape>
<BoundingBox>
<TopLeft>
<Latitude>55.9671898</Latitude>
<Longitude>12.4158802</Longitude>
</TopLeft>
<BottomRight>
<Latitude>55.6408501</Latitude>
<Longitude>12.5335598</Longitude>
</BottomRight>
</BoundingBox>
<Leg>...</Leg>
<Leg>...</Leg>
<Summary>
<Distance>62581.0</Distance>
<TrafficTime>2916.0</TrafficTime>
<BaseTime>2916.0</BaseTime>
<Flags>motorway</Flags>
</Summary>
..etc
Can please someone help me solve this?
The combination of a via point (using the waypoint2 parameter) and alternative routes (using the alternatives parameter) is not supported within the Routing API as a single request.
The Routing API reference states:
alternatives
Maximum number of alternative routes that will be calculated and
returned. Alternative routes can be unavailable, thus they are not
guaranteed to be returned. If at least one via point is used in a
route request, returning alternative routes is not supported.
So you can either find:
a single route from A to B to C or
a multiple alternate routes A to B without intermediate waypoints.
Of course if you make two separate requests you could find:
A to B with alternative routes then
B to C with alternative routes
I am using Gracenote video services for the programming guide in my application. Within the guide, I display channel logos along with the channel name and number. In the past, I have retrieved channel logo URLs by using the URL_GET API query with the mode set to TVCHANNEL_IMAGE. Within the body of the query, I would include the Gracenote IDs for a set of channels (found in a TVCHANNEL_LOOKUP response). Below is an example query.
<QUERIES>
<AUTH>
<CLIENT>XXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</CLIENT>
<USER>XXXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</USER>
</AUTH>
<QUERY CMD="URL_GET">
<MODE>TVCHANNEL_IMAGE</MODE>
<GN_ID>251535939-B76CB793D827E8BE713DAEB9675ADED4</GN_ID>
<GN_ID>251539612-E293EAF3F3164B292AD102532BCB9AF9</GN_ID>
</QUERY>
</QUERIES>
The response to the query would return URLs that I could then download the logos from. This was working fine up until one week ago. Now, the response returns with no match.
<RESPONSES>
<RESPONSE STATUS="NO_MATCH">
</RESPONSE>
</RESPONSES>
Has the API for retrieving channel logos changed? If so, how and what is the new method for getting channel logos? Ideally, I would like to continue downloading logos on demand through an API similar to URL_GET.
Are you still able to reproduce this? I get a valid response back using your query example
<RESPONSES>
<RESPONSE STATUS="OK">
<TVCHANNEL>
<GN_ID>251535939-B76CB793D827E8BE713DAEB9675ADED4</GN_ID>
<URL TYPE="IMAGE" SIZE="110" WIDTH="67" HEIGHT="50">http://akamai-b.cdn.cddbp.net/cds/2.0/image/E9F4/7FE7/D525/9746_110.png</URL>
</TVCHANNEL>
<TVCHANNEL>
<GN_ID>251539612-E293EAF3F3164B292AD102532BCB9AF9</GN_ID>
<URL TYPE="IMAGE" SIZE="110" WIDTH="67" HEIGHT="50">http://akamai-b.cdn.cddbp.net/cds/2.0/image/F1D1/F628/A3FE/79E0_110.png</URL>
</TVCHANNEL>
</RESPONSE>
</RESPONSES>