Hi,
I re-made some tests. Sometimes it works, but I have to say that most of the time it fails.
By looking at the exchange between the browser and the server with Charles Proxy, I have the feel that it's the client (so the browser) that close the connection. But I'm not sure. I say that because I see that only a few byte are exchange when it fails :
URL
https://localhost:35000/www/afile.pdf
Status
Receiving response body...
Response Code
200 OK
Protocol
HTTP/1.1
Method
GET
Content-Type
application/pdf
Client Address
/127.0.0.1
Remote Address
-
Timing
Request Start Time
14/09/11 21:06:31
Request End Time
14/09/11 21:06:31
Response Start Time
14/09/11 21:06:31
Response End Time
-
Duration
-
Request Duration
16 ms
Response Duration
-
Latency
0 ms
Speed
0,02 KB/s
Response Speed
0,02 KB/s
Size
Request Header Size
402 bytes
Response Header Size
112 bytes
Request Size
-
Response Size
15,89 KB (16272 bytes)
Total Size
16,39 KB (16786 bytes)
Request Compression
-
Response Compression
-
When it fails, the response size is only 16272 bytes (it should be 256175)
But I'm sure that with getOutputStream( true ) it always works on my laptop.
Thanks and regards
David
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: mercredi 14 septembre 2011 10:51
To: users_at_grizzly.java.net
Subject: Re: Grizzly 2 and SSL
Hi David,
on my laptop your sample works fine in all cases :(
I'll try Windows 7 later on.
Regarding the failure, wanted to ask more details.
The failure is *always* reproducible, the download never succeeds with enabled SSL + non blocking streams?
According to the stack trace you sent the failure happens when we try to read and unwrap secured data, so as I understand, it should happen before our HttpHandler takes over control. So currently I'm not sure how output stream mode may affect the SSL read.
Thanks.
WBR,
Alexey.