JettyにSecurityを。DIGEST認証(続き)

昨日の続き。

ドエライ事態に陥りました。

環境から言うと、
Windows7、FlashBuilder4.6で、AIR開発(FlexSDK4.6)
同PCで、FlashBuilder4.6でScalaプロジェクトでJetty起動、デバッグしています。

ここで問題になったのが、
JettyにDIGEST認証設定して、AIR側で、

URLRequestDefaults.setLoginCredentialsForHost("localhost","user","pass"); 

を実装します。
認証を通る事は出来ますが、この後、AIRからJettyの特定のディレクトリのXML
URLLoaderを使って、取得しています。
この瞬間、そのXMLJavaが掴んで離さないです。
ファイルの削除が失敗するので、気づいたのですが、
エクスプローラーから直にファイル削除しようとすると、
Java(TM) Platform SE binalyによって、ファイルが開かれている為、操作を完了出来ません」
とエラーが出ます。
File.delete()は、失敗しても何故かExceptionが発生せず、
FileUtils.forceDelete()を実行すると、IOExceptionが発生します。

単純な疑問として
URLLoader使って、ロードしただけなのになぜJavaがファイルを掴む?
同一PCだから、何かあるのかと思い、
Jettyを別PCに入れて、URLLoaderして見ましたが、結果同じでした。
DIGEST認証だから、何かあるのかと思い
BASIC認証に変えて、URLLoaderして見ましたが、結果同じでした。
ワカラーン

URLRequestDefaultsが何かあるのかと思い、
URLRequestに個別にヘッダーを設定してみたら、結果変わりました。

var auth:String = "user" + ":" + "pass";
var encoder:Base64Encoder = new Base64Encoder();
encoder.encode(auth);
var header:URLRequestHeader = new URLRequestHeader("Authorization", 'Basic ' + encoder.toString());
request.requestHeaders.push(header);

どういうことだ・・・。
素人考えですが、Javaがファイルを掴むということは、Jettyが悪い?
でも、Requestの方法変えると、大丈夫・・・。
ちなみに、ブラウザで認証して、ブラウザでXMLを表示すると、ファイル掴まない。
ということは、URLRequestDefaultsが悪い?
それとも私が悪い?

直感であれですが、URLRequestDefaultsなんとなく怪しい気がする・・・。
ちょっと風にあたってこよう。

追記)
罠がまってました。AIRが原因ではありません。
http://d.hatena.ne.jp/nosa1/20120214/1329182933