Hi,

We are using NTLM authentication with a Flex client. Every thing goes okay,
the calls that use HTTPService negotiate the exchanges (via Internet Explorer)
fine, e.g. here is a snippet of a successful exchange:


REQUEST ----------------------------->
GET /dso/session.htm HTTP/1.1
Accept: */*
Accept-Language: en-AU
Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
x-flash-version: 9,0,124,0
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M +T6bxhicNRVal/wgDj6Jmx4bCRU0zR
aOWUffdI6i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET
CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Host: 127.0.0.1:8888
Connection: Keep-Alive

RESPONSE ----------------------------->
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5; Path=/dso
WWW-Authenticate: NTLM
Connection: Keep-Alive
Content-Length: 0
Date: Tue, 11 Nov 2008 00:24:04 GMT

REQUEST ----------------------------->
GET /dso/session.htm HTTP/1.1
Accept: */*
Accept-Language: en-AU
Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
x-flash-version: 9,0,124,0
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M +T6bxhicNRVal/wgDj6Jmx4bCRU0zR
aOWUffdI6i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET
CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Host: localhost:8888
Connection: Keep-Alive
Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
Authorization: NTLM
TlRMTVNTUAABAAAAB7IIoggACAAwAAAACAAIACgAAAAFASgKAA AAD0c4MTAwNzAzSU5URVJOQUx=

RESPONSE ----------------------------->
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: NTLM
TlRMTVNTUAACAAAAEAAQADAAAAAFAoEAfyr4iuLClfwAAAAAAA AAADYANgBAAAAASQBOAFQARQBSAE4A
QQBMAAIAEABJAE4AVABFAFIATgBBAEwAAQAaAEoAQwBJAEYAUw A5AF8AMQA0ADkAXwA4AEUAAAAAAA==
Connection: Keep-Alive
Content-Length: 0
Date: Tue, 11 Nov 2008 00:24:04 GMT

REQUEST ----------------------------->
GET /dso/session.htm HTTP/1.1
Accept: */*
Accept-Language: en-AU
Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
x-flash-version: 9,0,124,0
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M +T6bxhicNRVal/wgDj6Jmx4bCRU0zR
aOWUffdI6i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET
CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Host: localhost:8888
Connection: Keep-Alive
Authorization: NTLM
TlRMTVNTUAADAAAAGAAYAHwAAAAYABgAlAAAABAAEABIAAAAFA AUAFgAAAAQABAAbAAAAAAAAACsAAAA
BQKAAgUBKAoAAAAPSQBOAFQARQBSAE4AQQBMAEEAUABhAHQAdA BlAHIAcwBvAG4ARwA4ADEAMAAwADcA
MAAzAPVsPO48S8VWr7PAUZJBy9//U4KoBUTj0nOKpwnje0pQ9K 4FZP6ClW3pKFChYcHFEw==
Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5

RESPONSE ----------------------------->
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-AU
Content-Length: 38
Date: Tue, 11 Nov 2008 00:24:06 GMT

Which is great. But when we try to use the File reference class we run into
the IE Post optimisation problem where:
[Q]
See http://lists.samba.org/archive/jcifs...er/006554.html for the
full message.
Microsoft has implemented a performance
enhancement in IE which prevents IE from sending any POST data to a server
once NTLM has been negotiated with that server. This was done because IE is
assuming that the server will require the browser to re-negotiate NTLM for
the POST request. IE is preemptively assuming that the response from the
server will be a HTTP 401 response and that the server will do no processing
on the request. It therefore does not waste the bandwidth to supply all of
the POST data in the initial request which is sent with the NTLM type 1
message. (This could be considerable savings depending on the actual size
of the POST data.) Once the server rejects the initial POST request from
the browser and responds with the NTLM type 2 message, the browser will
issue a second request containing the NTLM type 3 message along with the
desired POST data.
[/Q]

So basically the same negotiatation should happen, except that part of the
negotiation is pre-empted by the Flash/IE and the exchange starts with an empty
POST and a type 1 NTLM handshaking message... which is what does happen...
however once the server replies with a proper type 2 NTLM message Flash/IE
doesn't send any reply... (see the exhange below):

POST /dso/uploadFile.htm;jsessionid=4558DD04E3389077D56 79EC4F921CEC5 HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data;
boundary=----------Ij5cH2cH2GI3Ef1KM7Ef1gL6gL6cH2
User-Agent: Shockwave Flash
Host: localhost:8888
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
Authorization: NTLM
TlRMTVNTUAABAAAAB7IIoggACAAwAAAACAAIACgAAAAFASgKAA AAD0c4MTAwNzAzSU5URVJOQUw=
Content-Length: 0

HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: NTLM
TlRMTVNTUAACAAAAEAAQADAAAAAFAoEA6nBCzTE+sXIAAAAAAA AAADYANgBAAAAASQBOAFQARQBSAE4A
QQBMAAIAEABJAE4AVABFAFIATgBBAEwAAQAaAEoAQwBJAEYAUw A5AF8AMQA0ADkAXwA4AEUAAAAAAA==
Connection: Keep-Alive
Set-Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
Content-Length: 0
Date: Tue, 11 Nov 2008 00:24:21 GMT


So the question is why does FileReference behave in this way while HTTPService
is fine?

Forgot to mention that to get the NTLM exchange to happen I have to actually
add the session id (jsessionid) to the URL. If this is omitted then the POST
sends the content (without negotiating), this would be fine except for the fact
that it doesn't send a header with the session id either so the server side
gets a bit lost...

Ignore the last message, I don't have to append the session id.

Here is the snippet of code:
var file:FileReference;
var uploadURL:String = Server.instance.baseURL;

uploadURL = uploadURL + "/uploadFile.htm";
file = uploadScreenValue.fileRef

var request:URLRequest = new URLRequest(uploadURL);

try {
file.upload(request,file.name,false);
} catch(error:Error) {
trace("unable to upload the file");
}

Okay just read the FileReference documentation. Does anyone know why FileReference doesn't support authentication?