I extend that Apple made other changes as well. Specifically that
when the
"QuickTime Plugin.webplugin" is used, Safari hands off all web
interaction
for QuickTime to the plug-in itself, including authentication
exchange.
Correct, a Safari plug-in is responsible for downloading data
itself whereas the browser downloads data for a "Netscape style" plug-
in. FWIW, an ActiveX control in IE is also responsible for
downloading its own data.
From a few additional tests it would appear that QuickTime doesn't
support
authentication - period.
Incorrect, QuickTime (and the system networking services it uses)
handle several types of authentication, though clearly there is a bug
somewhere in the stack with the authentication method used by your
server.
Please write up this problem, with as much detail as possible so
we are able to reproduce it ourselves:
In general Apple asks developers to file their own bugs because it
emphasizes that the issue is affecting real developers. This also
has the added benefit that you can track the bug's status yourself.
