[Chandler-dev] Use of OPTIONS instead of PROPFIND

[Grant Baillie]

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

> On May 16, 2007, at 2:23 PM, Jared Rhine wrote:
>
>> What follows is an inquiry about the advisability and effort of  
>> using HTTP "OPTIONS" instead of "PROPFIND" for Chandler to  
>> determine if a given URL is a DAV URL.  The inquiry is primarily  
>> directed to Morgen.
>>
>> I've spent a couple days looking at the server-side of a real- 
>> world Morse Code driven service looks like.  The standard pattern  
>> for a synchronization is a 4-transaction HTTP set:
>>
>> 71.202.115.113 - - [16/May/2007:13:45:17 -0700] "PROPFIND /pim/ 
>> collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0  
>> HTTP/1.1" 501 1238 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386;  
>> en_US)"
>>
>> 71.202.115.113 - - [16/May/2007:13:45:17 -0700] "HEAD /pim/ 
>> collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0  
>> HTTP/1.1" 200 - "-" "Chandler/0.7.dev-r14332 (Linux; U; i386; en_US)"
>>
>> 71.202.115.113 - - [16/May/2007:13:45:17 -0700] "GET /pim/ 
>> collection/723886a6-705d-11db-8ee8-99b22f7fce88?ticket=1zaf4xxac0  
>> HTTP/1.1" 200 5533 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386;  
>> en_US)"
>>
>> 71.202.115.113 - - [16/May/2007:13:45:17 -0700] "GET /mc/ 
>> collection/723886a6-705d-11db-8ee8-99b22f7fce88 HTTP/1.1" 200  
>> 1243606 "-" "Chandler/0.7.dev-r14332 (Linux; U; i386; en_US)"
>>
>> So, it's a PROPFIND + HEAD + GET /pim + GET /mc.
>>
>> The initial PROPFIND operation helps Chandler determine if it's  
>> working with a DAV-based URL.
>>
>> Essentially every Chandler-driven PROPFIND against the server will  
>> fail.  This is per the design.
>>
>> However, it tweaks a little muscle in my sysadmin head: looking  
>> for 5xx errors in an access log is one of the primary ways to tell  
>> if something is breaking on the server.  You better pay attention  
>> if that metric suddenly spikes.
>>
>> So I've a mild aversion to a regular, everyday operation  
>> generating what looks like an exception condition.
>>
>> All Chandler is trying to do is figure out if the URL is a DAV  
>> URL. There's already a standard WebDAV mechanism to determine  
>> this; it's the HTTP OPTIONS method.
>>
>> I hesitate to even ask the question as what we have now works, and  
>> it'd be a Morgen task, and Morgen is quite the busy camper these  
>> days.  But the question is out there now, and I'm guessing I'll  
>> get a pretty reasonable answer that a good balance of these concerns.
>>
>> Thoughts?
>>
>> -- Jared
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev