[Chandler-dev] Use of OPTIONS instead of PROPFIND

[Morgen Sagen]

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?


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