Pamela,
As Erik indicates, your post is somewhat vague. The key thing to understand
here is that when a page in a browser has a form that can be submitted, the
form makes an HTTP post to the forms "ACTION" target URL. That URL is
normally an HTTP Listener like IIS, usually (but not always) to the same page
from which the page in the browser came from.
So the bottom line is that if you expect to be able to "Intercept" this post
in some way, unless the original page in the browser was generated and sent
out by some other infrastructure than IIS, you are pretty much tied into the
framework from whence it came.
You can have ISAPI filters in IIS, and UrlRewriters / HttpHandlers in
ASP.NET that can approach what you are describing, but the bottom line is
that the post has to be over HTTP.
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"pa***********@libero.it" wrote:
I am new to asp.net.
I have an asp page with a submit button which sends out some
information.
Instead of having IIS to respond and deal with this information, I
would like to have a .NET program (for instance a .NET service, or even
a client .net application) which is able to intercept this call and
deal with the associate information. This middle application might
decide whether to send something to IIS or just do everything by itself
and respond to the browser..
I would be grateful if you could give indications on how to implement
the key parts of this architecture (intercepting the info associated to
submit or other asp call and the talking back with the browser and in
case sending something to IIS). Pointer to demos or code snippets are
particularly appreciated.
-Pam