Redirecting to another site with a large querystring
joe
I have a website set up on our server that is especially for errors.
When another website encounters an error, it will redirect to this
site with error details in the querystring. The error website process
the querystring and displays a nicely formatted error message with
details.
The problem I am having is that the querystrings are getting too long
and I am unable to successfully redirect to the error site. What are
my options other than using querystrings? The error website is a
separate project from all of my other websites, so I think that cuts
down on my options. I would prefer not to have to do anything
database-wise.
Thanks!
![Mark Rae [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Mark Rae [MVP]
news:8aa6d558-005a-4bd4...@m36g2000hse.googlegroups.com...
> The error website is a separate project from all of my other websites, so
> I
> think that cuts down on my options.
It does, but I'm really curious as to why you would have a completely
separate website *just* for displaying errors...
Standard exception handling and user notification are excellent candidates
for a library project which you just add in to your "real" (for want of a
better term) websites so that the code is maintained in one place but
deployed everywhere it's needed. Then you wouldn't need to worry about query
strings or anything like that...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
joe
> "joe" <cole.m...@gmail.com> wrote in message
I have a seperate website so errors are displayed in a conistent way.
The processing is done in a class library, notification is sent, and
then the last step is redirecting to this page.
Can you give an example of how I could modify my class library to
display an error page that looked consistant across applications? I
think maybe our lines of thinking are on a different page.
vMike
"joe" <cole...@gmail.com> wrote in message
news:8aa6d558-005a-4bd4...@m36g2000hse.googlegroups.com...
You might look into HttpWebRequest and HttpWebResponse to handle this.
Mike
Cowboy (Gregory A. Beamer)
the majority of your code that does work is in your ASP.NET pages, which is
an issue.
The easiest way to set up consistency is to use the same controls to display
the errors. This will consist of a processing library (in most cases) and a
control. The control can be a user control, which you copy to each site, or
you can create a server control. A user control is faster, but you have to
remember to include it. If you use a server control, you can place the bits
in the GAC and force all apps to use the latest. This will make it so you do
not have to update multiple sites when you change the error methodology,
which is why I assume you are doing a separate site.
As for continuing the way you are doing it, consider sending the information
in a form collection that you build. It is a bit more consuming, but you can
send as much FUD as you need. I would consider this an interim step, at
best.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss
or just read it:
http://gregorybeamer.spaces.live.com/
*************************************************
| Think outside the box!
|
*************************************************
"joe" <cole...@gmail.com> wrote in message
news:8aa6d558-005a-4bd4...@m36g2000hse.googlegroups.com...
Mark Rae [MVP]
> I have a seperate website so errors are displayed in a conistent way.
> The processing is done in a class library, notification is sent, and
> then the last step is redirecting to this page.
I realise *what* you're doing - I just don't understand *why*... :-) N.B.
I'm not saying that you are wrong or that your method is bad...
> Can you give an example of how I could modify my class library to
> display an error page that looked consistant across applications? I
> think maybe our lines of thinking are on a different page.
1) Create a new project called e.g. errors
2) Add a web page (e.g. error.aspx) which will display the error to the
user.
3) Add a public class which will handle your processing logic - include a
public method called e.g. ProcessError
4) Add the project to any solution which needs it - this is even easier if
you're using a source control solution e.g. Visual SourceSafe 2005...
5) In your code-behind, include standard try...catch and/or
try...catch...finally exception handling which will call the ProcessError
method and, finally, Response.Redirect to error.aspx which will display the
error to the user.
6) Add code in the "main" sites' Application_Error method in Global.asax to
catch any unhandled exceptions.
joe
> "joe" <cole.m...@gmail.com> wrote in message
Thanks for the input. My setup is similar to how you mention, except
I didn't realize I could include entire web forms in a class library.
I am a going to dabble with that now. Thanks!
joe
> "joe" <cole.m...@gmail.com> wrote in message
Maybe I'm not understanding correctly - it sounds like you are
advising me to have two web projects in the same solution - one that
contains my error.aspx and ProcessError method, and another which is
my "main" project. Is this correct? If so, how am I supposed to
redirect from a form in one project to the error.aspx form in another?
Mark Rae [MVP]
> Maybe I'm not understanding correctly - it sounds like you are
> advising me to have two web projects in the same solution - one that
> contains my error.aspx and ProcessError method, and another which is
> my "main" project. Is this correct? If so, how am I supposed to
> redirect from a form in one project to the error.aspx form in another?
The second project is really just somewhere to store the error files...
With a source control such as Visual SourceSafe you simply drag the "shared"
files into whichever project needs them. That way, you can edit the shared
files in any of the projects in which they are used, and that will
automatically update them in all other projects in which they are used...
joe
> "joe" <cole.m...@gmail.com> wrote in message
I see. Thank you for your advice!