Charles is really great, it will show SOAP or REST request/response in a nice layout, and the greatest thing: it can act as a HTTPS proxy, so you can see the unencrypted data! The only downside is that I wasn't able to get it to work with Outlook 2011 and a HTTPS Exchange server (it will always return a 401 Not Authorized response). Since I really need to see the unencrypted data (my Exchange hosting provider only allow HTTPS), I'm using Charles to act as a HTTP/HTTPS proxy. But since it log the packets, if the data is encrypted, you can't see unencrypted. You can use rules to specific which host(s) or port(s) that you want to sniff, which is quite useful. tcpflow allows use to see TCP trafic, on a specific network interface. To achieve this, I use a couple of tools: Since I'm working on CalDAV/CardDAV, Exchange Web Services and Zimbra SOAP APIs, I often need to see what's happening on the wire. Other CalDAV implementations don't allow you to share individual calendar collections by iCal/Calendar.app (but some will allow you to share them by doing it by their Web interface, like Zimbra or Kerio Connect). To my knowledge, only iCal Server 10.7 and 10.8, or CalendarServer (the open source version of iCal Server) implements it. This is for servers that implements the caldav-sharing draft. 4) Users can "subscribe" to the shared calendar by clicking on a URL and authenticating in their browser using their calendar server credentials: 3) Assign the group as a read-only or read-write proxy of the resource using the command line proxy management tool. (the command line tool is: calendarserver_manage_principals). If you don't have the wiki available, then you can do something similar with resource calendars: 1) Create a resource for "Movie Editing". Users who are members of a wiki can directly "subscribe" to the wiki calendar via a special sharing mode that involves simply clicking a link in the wiki calendar - that will "bind" the wiki calendar into the user's calendar home where it appears as if it were a calendar shared by an individual. So I asked the list, and it seems the best ways to share calendars with groups instead of inviting every member of the group directly are: Are you using icalserver standalone or as part of OS X server? With OS X server the wiki feature does offer a way to manage group calendars via the wiki group membership. So I added an existing email address to the group's OD record, but the problem is that it's the user who receive the invitation and must accept it in iCal. In Open Directory, groups don't have email addresses by default, so I said: "hey, let's add one with dscl!". Why? Because even if the invitation is not sent by email, the user or contact that is going to get the invitation must have an email address. I need to share calendar collections from iCal Server to groups, but sadly, with CalDAV it doesn't work. So, the message is: if you want to test bad behaviour against a CalDAV implementation, Google Calendar or CGP are quite good candidates. I really don't know why they are doing this, but if you create a calendar in your own account, it shouldn't show up as a proxy since it's one of your own calendars. When you add a new calendar collection to Google Calendar, it show up as a proxy.It didn't even have a DAV principals collection! CommuniGate Pro returns a "HTTP/1.1 500 mailbox with this name already exists" status code, with the body as HTML! Again, if a MKCALENDAR fails because the URI already exists, it should return a 403 Forbidden code, with a XML body that explains the error.But CommuniGate Pro returns a 200 OK status instead. The CalDAV says that a successful MKCALENDAR request should return a 201 Created status.But CommuniGate Pro and Google Calendar, oh boy! Same thing for Fruux (which uses the SabreDAV framework). Kerio don't support as many extensions as iCal Server, but they follow the RFCs quite well. It's really the best CalDAV implementation out there. I have nothing bad to say about iCal Server. When I test new stuff and want to see the behaviour, I test against: I'm contributing a lot of code to cdav-connector, a CalDAV/CardDAV library for Hava.
0 Comments
Leave a Reply. |