469,362 Members | 2,600 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,362 developers. It's quick & easy.

IE under HTTPS with a file input gives a page cannot be found

Client page: <input type="file".....>
Server: Apache, OC4J, J2EE app
XP, SP1 and updates

Works perfectly under HTTP.
However, under HTTPS the user needs to hit the submit button really
fast to
avoid a "page cannot be displayed". All other interaction with the
application works well.

As a workaround one can set the http-connection on the server as
use-keep-alives = "false" or increase the
oracle.j2ee.http.socket.timeout.

In my opinion this is a bug in IE as the browser does not make contact
to
the server before displaying the error. I do not see this bug in the
buglist
of IE.
Does anyone else has experienced the above?
--
Beste regards,

Chris

Feb 16 '06 #1
6 4119
VK

chris wrote:
Client page: <input type="file".....>
Server: Apache, OC4J, J2EE app
XP, SP1 and updates

Works perfectly under HTTP.
However, under HTTPS the user needs to hit the submit button really
fast to
avoid a "page cannot be displayed".


"Really fast" after what? After a local file is chosen for input-file?
That cannot be true.
"Page cannot be displayed" is only possible with a failed request, and
request cannot fail until you submit the form. So there is something
else in your situation you shoud possibly explain.

Feb 16 '06 #2
Thanks for your reply.

Really fast depends on the oracle.j2ee.http.socket.timeout. In my case,
10 seconds after choosing a local file as input-file..
It is a strange problem only occuring under HTTPS with a server-setting
of use-keep-alives=true. This is regarding performance the recommended
setting. We use a web-cache so use-keep-alives can be set to false
without performance suffering too badly.

The HTML:
<form name="PilotageExemptionsUploadFormBean" method="post"
action="/referencedata/pilotageexemptions/pilotageexemptions.do"
enctype="multipart/form-data">
<table class="ContentTable" cellspacing="1">
<tr>
<td class="ContentCell" width="20%">Bestand</td>
<td class="ContentCell" width="20%"><input type="file"
name="fileName" value="" style="width: 250px"></td>
</tr>
</table>
<br>

<div align="right">
<input class="InputButton" type="submit" style="width: 150px"
onClick="doAction('returnToStart','true'); return false;"
value="Cancel">
<input class="InputButton" type="submit" style="width: 150px"
onClick="doAction('save','true'); return false;" value="Laad">
</div>
</form>

Feb 16 '06 #3
Extra comment: The error only occurs after the user hits the submit
button.

Feb 16 '06 #4

chris wrote:
Extra comment: The error only occurs after the user hits the submit
button.
As VK said from above, the page containing the file upload form is not
the problem. It is only after you hit submit which causes the problem.
<form name="PilotageExemptionsUploadFormBean" method="post"
action="/referencedata/pilotageexemptions/pilotageexemptions.do"
enctype="multipart/form-data">


After you have submitted your form, the request will be sent to the URI
that you have given in the action attribute. Since the page cannot be
found, go ensure that the page, in this case,
/referencedata/pilotageexemptions/pilotageexemptions.do, can be reached.

Feb 16 '06 #5
Thank you for replying.
The page can be reached. If the user hits the submit button fast enough
it is reached. Our webapp both runs under http and https. Under http
the page is always reached. Under https the only way to fix the problem
of "page cannot be displayed" seems to be to
set use-keep-alives to false or increase the
oracle.j2ee.http.socket.timeout considerably.

I also noticed the browser not contacting the server when the problem
occurs.
As said there are a few problems with https noticed by Microsoft and
other usegroups but this particular one I did not encounter.
I think it is a particular IE under XP problem.

Feb 16 '06 #6
VK

chris wrote:
Thank you for replying.
The page can be reached. If the user hits the submit button fast enough
it is reached. Our webapp both runs under http and https. Under http
the page is always reached. Under https the only way to fix the problem
of "page cannot be displayed" seems to be to
set use-keep-alives to false or increase the
oracle.j2ee.http.socket.timeout considerably.

I also noticed the browser not contacting the server when the problem
occurs.
As said there are a few problems with https noticed by Microsoft and
other usegroups but this particular one I did not encounter.
I think it is a particular IE under XP problem.


There is nothing wrong with HTTPS support under IE.
Definitely frequent hit on the submit doesn't affect on HTTPS protocol.

But HTTPS is a *very* expensive protocol as it requires every byte to
be encoded before send to SSL to either side (this is why btw it is a
very bad idea to use large/numerous pictures on HTTPS server).

It is possible to guess that IE opens channel when the form ready for
submission (thus the upload file is converted into base64). It is also
possible to guess that the actual data transmission starts only when
data is ready (thus base64 crypted by the public key). The delay
between two events may lead to timeout if server socket is too
"impatient". Numerous submits create a request queue so finally one of
requests has something to send with success.
I would suggest to use the standard in-out schema instead: HTTPS is
used for secure authentification only, after that you're working with
regular HTTP.

Nothing JavaScript can do for you though.

Feb 16 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by YoBro | last post: by
2 posts views Thread by ypul | last post: by
reply views Thread by Chris Carter | last post: by
6 posts views Thread by tshad | last post: by
3 posts views Thread by Andee | last post: by
2 posts views Thread by Claudia Fong | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.