I think the better question  is what you are actually trying to do? Most of the
SharePoint functionality happens at the server level in an ISAPI filter, so
chances are doing something in client-side script is waaaay too late. If you
are trying to just run an ASP.Net web  app on a SharePoint server without using
any SharePoint functionality, you need to look into Managed Paths and excluding
the URL to your application.

I am getting the information third hand myself. Yes, by the time the
SharePoint client has tried to access the server it is far far too
late, because it is sending the SharePoint packets to the wrong
server.

What I am trying to do is get my web  form to submit  itself to its
own server. What seems to be happening is SharePoint is intercepting
the document.forms[0].submit() in my application and trying to use my
web server as if it were the SharePoint server. To clarify: I am
trying to determine if SharePoint is running and automatically handle
that.

Second choice is to determine if SharePoint is running and tell the
user to take action. Third choice (current action) is to determine if
the browser is MS-IE and present a warning during authentication.

What exactly is "your server" - a seperate box, a seperate vserver, a seperate
vdir, or something else? Where is the SharePoint instance that you think is
causing problems? Where is the form being served from and how is it being
displayed?

The page is being served by an IBM-Lotus Domino server installed on a
separate box from MS-SharePoint and is being viewed using any web
browser: the problems only occur with MS-IE for those users with
MS-SharePoint active. They are loosing their work  when trying to
submit work in my application. For example, the user is fully
authenticated with the Domino server when an unauthenticated GET such
as the one below is made:

255.255.255.255 foo.bar.com - [08/Jun/2005:11:59:03 -0500] "GET
/MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=4219&STRMVER=4&CAPREQ=0
HTTP/1.1" 302 - "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
.NET CLR 1.0.3705)"

The only times a GET to "/MSOffice/cltreq.asp" is recorded is when the
end user has SharePoint active.

To clarify, I am not a SharePoint developer: I just want my
non-Microsoft application to run properly when MS-SharePoint is
installed and active. I want to stop MS-SharePoint intercepting the
document.forms[0].submit() in my application.

Ok, so here's a few thoughts:

1) SharePoint is a server application - if your app is installed on a separate
server there's no way SahrePoint can intercept your form submit  events unless:
- your form is being displayed inside an iframe on a SharePoint site
- your form is being displayed inside the Office Save dialog
2) The URL you list from the log is generally 1 of 2 things:
- an IE6 discussion  request
- the Nimba virus
neither of which have anything to do with SharePoint (at least not the current
version). What version and application (SharePoint Team Services, WIndows
SharePoint Services, SharePoint Portal Server 2001 or Portal Server 2003) are
you talking about?
3) I'm trying to figure out what you mean by "installed and active" - like I
said in (1) SharePoint is a server application. There is a small client portion
in Office to allow direct saves from Office to the server, but nothing in IE
itself.

Maybe it would help if you could do a simple walkthrough of what your app does
and where so I can see if there's anything that throws a red flag...

I have passed your questions and observations on. The very good news
is that my client is accepting my software is not the cause of the
problem, but I probably need to be party to the cure.

Sorry for not describing the situation correctly ... please put this
down to my total ignorance of this product and third hand information:
yes, this seems to be an MS-Discussion related issue [what ever that
is], but from the way it is being described to me, only occurs when
the end user has MS-SharePoint installed. To partially quote: "...
because of the Sharepoint discussion  toolbar".

I appreciate your help. I am sure some screen shots would help you to
diagnose this quicker.

Ok, that makes a bit more sense. SPS 2001 and STS included this toolbar, but
it's no longer included in the current products.

It seems that the problem has
been limited to people who have not been upgrading their machines in
accordance with my clients' corporate policy!