Redirecting to another site with a large querystring

[joe]

Hello,
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!

 

[joe]

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...

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]

Hello,
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!

You might look into HttpWebRequest and HttpWebResponse to handle this.
Mike

 

[Cowboy \(Gregory A. Beamer\)]

Seeing that the reason for a separate site is for consistency tells me that
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.

 

[joe]

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...


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.

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]

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...


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.

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?

 

[joe]

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...

I see. Thank you for your advice!