when trying to upload a file in workspaces using Microsoft Internet Explorer,
we're getting an error page (server or DNS cannot be found).
File upload in the Content Services Web Application times out.
We changed the necessary settings in ocsclient_apache.conf and um_sso.conf as described in the Oracle Collaboration Suite Security Guide, Chapter 2.9.1 "Relaxing Security to Enable Downloads Using Microsoft Internet Explorer", unfortunately it didn't help. We also tried to change registry settings as described in some Metalink notes.
It still doesn't work.
The errors occur only when using Microsoft Internet Explorer since SSL has been
enabled. Firefox works fine but most of our clients are using IE.
Single Box Installation 10.1.2 with latest patchsets
Apache Reverse Proxy
It seems to be a client issue - the failing requests do not reach the server because we can't see any log entry even at the reverse proxy.
We opened a SR end of July but Oracle support services is not able/willing to solve the problem until now.
This issue is being followed up on via the standard SR/Oracle support channels.
Summary: The file upload problem is not a Workspaces-specific issue. It is a client issue with IE 6. IE 7 release candidate 1 works (as does firefox).
Oh, that's fine. Same suggestion as Oracle Support services. Oracle makes software for beta testers (IE7 Release Candidate) and users of niche products (Firefox).
I'm sorry, but we have no influence on the IT infrastructure of our customers which are using our portal - so we will have to tell them that they cannot use content/workspaces because they have a common used infrastructure (IE6 is still the most used browser).
This is what I've determined (netstat, watching connection packets, checking microsoft.com)
older versions of wininet.dll don't recognize the 'conversation over' signal sent by the web server. So, IE thinks the conversation is still open and tries to send data. And we all know communication problems are the root of all evil.
So, you can either get absolutely everybody to stop using IE 6 (HA!), or you can change your web server's KeepAliveTimeout to some value > 60 seconds (IE's default timeout). This allows IE to determine when the conversation is over (Typical MS demanding to be in control of everything).