from feedback:
We connect to our servlet often using mixed packets of ASCII and
non-ASCII (often compressed) data. This works perfectly when unning as an
application, but when running is webstart this causes an error.
What happens is this:
ASCII data can be sent through an HttpURLConnection always, owever, if any
non-ASCII data is sent with webstart, the application reports an error
indicating that it cannot connect to the web server. Really, it does not
even try (according to the webserver logs). Have you had a chance to
investigate this issue yet? I know I sent in the bug report ust last week,
but I recommended webstart and need to know soon if I need to ut webstart
on hold. This is a definite show-stopper.
Incidently, the Netscape 4.* applet engine does the exact same thing with
binary data.
----------------
Connection bug: Review id 115884
JFileChooser bug: Review id 115723
This program shows both of the bugs listed above. The signed jarfile is
included.
I actually am getting different results with www.sun.com than I did
internally. I am not sure why. In any case, you can see that when (char)0
is sent to the webserver, different things happen than when it is not there.
I usually get a FileNotFoundException immediately, but when connecting to
sun I get the stack shown below. Maybe this is due to the routing through
the proxy. In this sample, I get a SocketException (below).
In any case, I would conjecture that these two cases should be the same, yet
they are not. Internally, I connect to a servlet, but I found that for this
test is does not matter. In this test I am connecting to www.sun.com and
sending it a string that it presumable ignores. This does not cause an
error. Add the null characters and bad things happen.
Mark
----------
We connect to our servlet often using mixed packets of ASCII and
non-ASCII (often compressed) data. This works perfectly when unning as an
application, but when running is webstart this causes an error.
What happens is this:
ASCII data can be sent through an HttpURLConnection always, owever, if any
non-ASCII data is sent with webstart, the application reports an error
indicating that it cannot connect to the web server. Really, it does not
even try (according to the webserver logs). Have you had a chance to
investigate this issue yet? I know I sent in the bug report ust last week,
but I recommended webstart and need to know soon if I need to ut webstart
on hold. This is a definite show-stopper.
Incidently, the Netscape 4.* applet engine does the exact same thing with
binary data.
----------------
Connection bug: Review id 115884
JFileChooser bug: Review id 115723
This program shows both of the bugs listed above. The signed jarfile is
included.
I actually am getting different results with www.sun.com than I did
internally. I am not sure why. In any case, you can see that when (char)0
is sent to the webserver, different things happen than when it is not there.
I usually get a FileNotFoundException immediately, but when connecting to
sun I get the stack shown below. Maybe this is due to the routing through
the proxy. In this sample, I get a SocketException (below).
In any case, I would conjecture that these two cases should be the same, yet
they are not. Internally, I connect to a servlet, but I found that for this
test is does not matter. In this test I am connecting to www.sun.com and
sending it a string that it presumable ignores. This does not cause an
error. Add the null characters and bad things happen.
Mark
----------