So now my application is logging into Sakai, pulling university affiliations, workgroups and sundry, and finding all the Sites bearing the mark of SOPI.
The Sakai access URLs are working fine; I'm pulling content I am supposed to be able to pull. The Quicktime Movie URLs are resolving into movies to present to the user. The user answers them - and I was about to crack the nut of uploading the recorded response movies to Sakai when I decided to use a faster remote host at the Client's facility.
So it's all going swimmingly, er, except if I use a HTTPS URL. That's not a big deal for the webservices. Nor for reading text files such as the XML manifest for the assessment media.
Apparently Apple never implemented a HTTPS transport URL resolver for quicktime.
What a headache to dig down into. I was sure that I had something screwed up with self-signed certs, certs not matching host names, and dorked with all sorts of work arounds. ( such as a custom no-op host name verifier )
I finally trawled the Apple Quicktime mailing lists and found a lone posting from a couple of years ago. Feh. An apple engineer suggested reporting a bug.
So I snork up some old IO code and securely spool the files locally only to re-read them into quicktime with a file:/// URL.
This was quite derailing.
However the national election results were a boost!