[Chandler-dev] Use of OPTIONS instead of PROPFIND

[Morgen Sagen]

On Jun 26, 2007, at 9:57 AM, Grant Baillie wrote:

>
> On 26 Jun, 2007, at 09:51, Morgen Sagen wrote:
>
>> I was thinking about this yesterday and it's possible that I could  
>> simply have Chandler start off with a GET of the URL.  Then,  
>> looking at the Content-Type header in the response, I could do the  
>> following:
>>
>> "application/eim+xml" -- hand the response body to the morsecode  
>> subscription code.
>> "text/html" -- parse the response body for a morsecode URL; if  
>> there is one embedded, GET the morsecode URL, passing new response  
>> body to morsecode; otherwise this could either be a regular web  
>> page or it could be a DAV collection, so I could then OPTIONS and  
>> look for a DAV header.
>> "text/calendar" -- hand the response body to the monolithic  
>> icalendar file parser
>>
>> Storing the response from the initial GET and passing it to the  
>> code that will eventually process it (rather than having that code  
>> go and fetch it itself as it does today) will take a little bit of  
>> work, but should be possible.
>>
>> How does this sound?
>
> Hmm... I think this would be wrong in the case of CalDAV  
> collections that return text/calendar for a GET of their collection  
> URL: You'd end up with a read-only .ics-style subscription instead  
> of a CalDAV subscription.
>
> I know cosmo used to be one such server, I'm not sure if other  
> CalDAV servers do it (Apple's might well, to support older versions  
> of iCal.app).
>
> --Grant

Right, Cosmo no longer does this, and I suppose I could do an OPTIONS  
following the  GET of a text/calendar to see if it's a DAV server  
after all.