i am currently trying to implement a „simple“ readonly CALDAV-interface for a system. But the synchronization protocol and the CALDAV-clients give me some headaches.
The main test client i use is the macos-calendar (sierra).
The initial handshake (DAV principle, calendar lookup) and inital load of data is working. I get some REPORT:calendar-query requests.
The issue is the incremental sync after initial load. There are two approaches:
Via WebSync-extension (REPORT:sync-collection and sync-token prop)
my main issue here is that provisioning the sync-token from the server is not trivial in my system. Changes and New data is not an issue, but physical deletion (not yet logged in the user context) and changes in the scope of group- and/or role-assignments. Maybe i need to consider to invalidate in complex cases the sync-token and let the client resetup without sync-collection?
A nasty workaround could be to retain the calendar item IDs send to the client and check on each request for their existence and responds if necessary with a not found per deleted/out of scope calendar item. But this would mean i store client-state on the server which doesnt sound right and might be error prone.
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1) requests no webdav-sync active)
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1). According to the protocol the client should determine the deleted items and remove them, but it doesnt do it in my case. Any ideas here?
For my system currently it would be ideal to use this approach though the performance might be not the ideal one.
With ios-Calendar i face another issue:
Initial handshake is somehow working as the requests in the network are coming and are answered.
But than a MKCALENDAR request is coming (instead of a calendar-query or propfind for items) which answer with 403 as i also dont provide it in the Allow-header of the options response. the request looks like this:
MKCALENDAR /services/cal/_userid/220EDB4A-F00C-41C9-B78F-10781BBA77E4/ HTTP/1.1
Host: 127.0.0.1:8003
Content-Type: text/xml
User-Agent: iOS/10.0.1 (14A403) dataaccessd/1.0
<?xml version="1.0" encoding="UTF-8"?>
<B:mkcalendar xmlns:B="urn:ietf:params:xml:ns:caldav">
<A:set xmlns:A="DAV:">
<A:prop>
<B:calendar-free-busy-set>
<NO/>
</B:calendar-free-busy-set>
<D:calendar-order xmlns:D="http://apple.com/ns/ical/">1</D:calendar-order>
<A:displayname>Kalender</A:displayname>
<B:calendar-timezone>BEGIN:VCALENDAR
...deleted....
</B:calendar-timezone>
<B:supported-calendar-component-set>
<B:comp name="VEVENT"/>
</B:supported-calendar-component-set>
</A:prop>
</A:set>
</B:mkcalendar>
Nothing is happening afterwards.
Anyone experiencing this as well? Why ios-calendar tries to do a mkcalendar though i have a calendar-collection as resource-type?
With Thunderbird Lightning:
Initial handshake with the calendar-collection is working
A propfind-and multiget request for items is answered with iCal-Items.
But they are not displayed and in the error log i receive:
Warnung: CalDAV: Get failed: CalDAV: Error: got status 200 fetching calendar data for Debug Proxy, null
(text in german: error code: 0x80004005) Warnung: Fehler beim Lesen von Daten für Kalender: Debug Proxy. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: 0x80004005. Beschreibung: CalDAV: Error: got status 200 fetching calendar data for Debug Proxy, null
(text in german: error code: READ_FAILED) Warnung: Fehler beim Lesen von Daten für Kalender: Debug Proxy. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: READ_FAILED. Beschreibung:
http channel Listener OnDataAvailable contract violation
a similiar response is though working in macos-calendar – could it be some encoding issue?
Any hints are highly appreciated!
This is indeed a pretty broad question. But let me try to address some stuff:
Via WebSync-extension (REPORT:sync-collection and sync-token prop) my main issue here is that provisioning the sync-token from the server is not trivial in my system
Even if it is hard for you, you should really try to come up with something here. Even if this means storing some extra info on the server. Sync-collection is way more efficient.
(Idea: Maybe you can at least set a flag when something actually got deleted and only then expire the sync-token?)
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1))
Which one, calendar-range-query or PROPFIND? Completely different things ...
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1).
If we are talking about a calendar-range-query, the client cannot proactively delete items since it doesn't know whether they just left the range (vs being deleted).
With PROPFIND it should do this. If you have proof it doesn't, maybe create another question with all the relevant details.
With ios-Calendar i face another issue: ... a MKCALENDAR request is coming ...
This probably means that it can't find the default scheduling calendar, no calendar at all, none with a proper component-type property. Or all the same for todos (Reminders app, same account). What is the payload of the MKCALENDAR?
Hard to diagnose w/o details, if you can't figure it out, ask a specific question on this with all the relevant details included (e.g. the XML you send in response to the home query).
Thunderbird Lightning
Can't say much about this, probably depends a lot on the version and what extensions you are using. AFAIK many people use the ScalableOGo Thunderbird extensions to get proper Cal/CardDAV with Thunderbird.
For Thunderbird/Lightning you may want to turn on calendar.debug.log and calendar.debug.log.verbose in the advanced config editor and restart. You can find it in Options > Advanced > General > Config Editor. This will get you more detailed http requests and information about what failed. You can also hook up the remote debugger and look at the network monitor, or set breakpoints in the code.
With Thunderbird/Lightning please note that we are using a mix of previous and current versions of the webdav-sync draft. I can't say much from the error message as is given it is very general, but it does look like there is something unexpected in the results.
Maybe it makes sense to compare the handshake between an existing server (like sabre/dav) and the client, then see where the difference between your communication and theirs is.
Also, you may be interested in the CalDAVTester from Apple, which checks server interoperability. Note however that it does contain various apple specific tests. The folks at CalConnect are working together with Apple to make it more generally usable and to split out the Apple-specific tests. Given your server is read-only, don't expect everything to work, but you can hunt for fixing specific tests.
Related
I am newbie on Fix in general and I have started from QuickFix to make practice. I apology in advance from the following trivial questions.
I have understood that to handle ExecutionReport I need to use crack() method inside FromApp() and implementing OnMessage().
But what I have two questions :
1) What happens if during a Partially fill order ExecutionReport message suddenly session drops, which is the way to handle this situation. Trying to reconnect and Send a request ? Please Can you provide a simple explanation in steps and what QuickFix Api method should I use ?
2) If I need to implement a FixEngine to handle dropcopy should I be aware of something in particular ?
Thank you for your help
1). Just make sure ResetOnDisconnect parameter is set to N for your trading session: ResetOnDisconnect=N (docs)
QuickFix will be automatically attempting to reconnect every ReconnectInterval seconds;
Once connected (with ResetOnDisconnect=N) it will also automatically exchange last known message sequence numbers with the FIX server, and the ones lost during the disconnection will be re-sent - so without a line of code you will receive the missing messages.
Also, if disconnection was for a longer period of time, you may want to send Order Status Request (H) message to the FIX server to receive actual ExecutionReport for your pending orders.
2) The question is too general for me to answer...
In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them.
Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me.
The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go)
Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?
If you change jdiameter's config to something like this:
<Network>
<Peers>
<Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
<Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
</Peers>
<Realms>
<Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
...
</ApplicationID>
</Realm>
</Realms>
</Network>
In your sbb, then you'll need to create a client session providing your custom realm using this method:
DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)
Example:
ccaRaSbb.createClientSession(null, "custom.realm")
where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface)
finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured.
Let me know if this makes sense to you
Posting the method I used to solve this problem.
As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file.
For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method)
I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm.
In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1.
Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs.
Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.
I am building a mailout capability and it is working OK as far as it goes. However, I want to distinguish between various potential (high level) outcomes in order to determine what happens to each message after the current send attempt.
This must be a common requirement so I seem to be missing something pretty obvious, but I can't find anything that addresses it, either here or via Google or on PHPMailer site or .. . Possibly because there are so many questions about specific errors that I just can't find anything useful in all the other results.
At very high level:
Attempt send, and assess resulting error/result. Identify whether this message has been sent, must be retried later, or failed permanently.
- success -> update message status as 'SENT: OK'
- sent, but some issues (e.g. one recipient failed, others processed OK)-> 'SENT: some error'
- failed, due to temporary problem (e.g. connection problem, attachment open) -> 'TRY LATER'
- failed, due to message-specific problem that we should NOT try to resend-> 'FAILED: some error'
As I was unable to find an existing resource with e.g. a table of errors, I spent some time working through the phpmailerException code to try to build one myself, but it's not simple because a) they don't appear to have been designed in terms of this kind of grouping logic, b) it is not easy to uniquely identify a particular error: PHPMailer provides human-friendly messages, which are different in different languages, rather than an identifiable code - given that my solution will need to work across different language installations that's a problem!
Obviously SMTP itself provides a range of errorcodes which I could potentially use for this purpose, but how do I access these via PHPMailer? (This would work for me as I only use SMTP at this point - however, this would NOT work if other message transport like sendmail was used, so I would prefer a PHPMailer solution)
If you want individual result codes for individual address, you really need to send each message separately. If you do get errors on some recipients, they will be listed in the ErrorInfo property - look in the smtpSend function to see how the error string is assembled. I agree that it's not especially easy to parse that info out. The error messages in PHPMailer are generally more for the developer than the end user, so the translations are not that significant. You can get slightly more information about errors if you enable exceptions rather than relying only on return values.
I need to access the Date: header when I handle the request, but this seems to be "swallowed" by the framework; any other header (even made up FooBar ones) show up and I can get them, but this gives me None (I'm using Postman to send a simple GET request - everything else works just fine):
println("Date: " + request.headers.get("Date").getOrElse("no date!"))
returns "no date!" no matter how I try to send something sensible.
I'm wondering whether this gets processed before the request object reaches my Action.
I need the actual string value sent, as this should be part of the request's signature - so an equivalent Date object representing the same value would not be of much use (as it needs to be part of the hash, to avoid replay attacks).
Just as a test, I replaced the Date header with a Date-Auth one, and this one shows up just fine:
ArrayBuffer((Date-Auth, ArrayBuffer(Wed, 15 Nov 2014 06:25:24 GMT))
Any ideas or suggestions greatly appreciated!
Are you sure there is a Date Header in your request (tested with tools like firebug or wireshark)?
Browsers do not need to send a Date header.
RFC 2616 (HTTP 1.1) from the Date section (14.18)
Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.
I stand corrected - it turns out that Chrome blocks a whole bunch of headers:
http://www.getpostman.com/docs/requests
I wrote a Python Flask test server and, in fact, the Date header is not there.
That page has also a fix, which works just fine with Postman Version 0.10.4.3 and Interceptor(1).
sorry for wasting everyone's time!
1 Incidentally, IMO Postman is the best REST client and has now also some awesome looks, beyond incredible functionality. If you're working with REST APIs, I highly recommend it.
I'm writing a REST based web service, and I'm trying to figure out the best way to handle error conditions.
Currently the service is returning HTTP Errors, such as Bad Request, but how can I return extra information to give developers using the web service an idea what they're doing wrong?
For example: creating a user with a null username returns an error of Bad Request. How can I add that the error was caused by a null username parameter?
According to the HTTP spec, the text that comes after the three digit response code, the "Reason-Phrase", can only be replaced with a logical equivalent. So you can't respond with 400 null user and expect anything useful to happen. Indeed, The client is not required to examine or display the Reason- Phrase.
In general, the HTTP response entity (typically the page that accompanies the response) should contain information useful to the client to guide them forward, even when the response is an error. On the web, most such errors are HTML, and are devoid of machine readable information, but most browsers do show the error to the user (and SO's error page is pretty good!).
So for a primarily machine readable resource you have two options:
Pass a human readable message anyway. Return 400 Bad Request with a HTML response, which the client may opt to show to the user. It's dead easy but it's a bit like throwing an unchecked exception, it passes all the hard work to the client, or indeed the end user.
Allow clients to recover. Return 400 Bad Request with a machine readable response which is part of your API, so clients can recover from known error conditions. This is harder, like throwing a checked exception, it becomes part of the API, and it allows clients to recover gracefully if they want to.
You could even make the server support both scenarios by defining a media type for the machie readable error recovery document, and allow clients to "accept" them: Accept: application/atom+xml, application/my.proprietary.errors+json
Clients that forget the mandatory field can opt in to getting machine readable errors or human readable errors by choosing to Accepting the error media type.
It's stated in the HTTP spec that most error codes should return some basic text that gives a clarification of why the error is being returned. The basic Java Servlet Spec defines the HttpServletResponse.sendError(int Code, String message) for this purpose.
String desc = "my Description";
throw new WebApplicationException(Response.status(Status.BAD_REQUEST).entity(desc).type("text/plain").build());