Working in asp.net, in VB I want a site visitor to be able to see a Member's page by going to i.e. almosbarn.com/tom. I need to extract the "tom" part, look it up in the database, then open tom's webpage. The lookup, database, and view page parts work. My problem is I've tried setting it up in the global.asax application_start to get the "tom" segment but I get the error "request is not available in this context". My code to capture it in the global.aspx application_start is:
Dim vMbrID = Httpcontext.Current.Request.URL.Segments.Last()
This works and gives me "tom" on a test page, but not the global.aspx page, where I get the error.
The Application_Start event is fired when an HttpApplication instance is first created. At this point, the request information is not available; there might not even be a request in progress.
You want your code to fire at the start of a request, so move it to the Application_BeginRequest event.
What you want to do is set up routing in your global.asax to let you handle these kinds of situations.
MSDN on routing
MSDN walkthrough on routing
Related
I have a webform that has a single page method. My other web apps log unhandled exceptions to the system event log on the web server. Since the other developers that I work with expect to see entries for app errors in the event log, I would like this app to do the same.
However, I have the app send error emails when an exception is caught from calling code inside the page method. It is not writing to the event log when this occurs. Note: the page method re-throws the exception after calling my email notification method.
From what I've read so far it seems that ASP.Net logs errors to the event log by default. I imagine that the same is not true for Page Methods/WebMethods because they basically throw the exception to the client code calling it.
Is there a trivial way to have that exception bubble up properly so that it writes to the event log? No other apps write to the event log directly from what I've seen so I don't think the application could create a new source since our security people keep a lot of things locked down (with good intentions, yay security).
[WebMethod]
public static object MyPseudoWebMethod()
{
try
{
// My exception spawning unreliable code here
}
catch(Exception ex)
{
// Cleanup ...
this.SendErrorNotification(ex);
throw; // <-- This doesn't bubble up but I'd love for it to!
}
}
Hmm interesting problem. You are right in that WebMethod exceptions do NOT follow normal exception flow.
The Application_Error event is not fired if your web method throws an
exception. The reason for this is that the HTTP handler for XML Web
services consumes any exception that occurs while an XML Web service
is executing and turns it into a SOAP fault prior to the
Application_Error event is called.
(from here)
The above page suggests using a SOAP extension to catch that exception before its swallowed, but here's how I'd do it if you don't want to do that:
1) Make a new 'error recieving' ASPX page that you will build that will take whatever params you want to record in your error log. So for example, have this page take in a POST named "ExceptionDetails" or whatever else you wish to capture. This page will NOT be viewed directly in a browser, so it doesnt need any ASPX controls or anything, but using a MasterPage on it won't hurt anything.
2) In the code behind of this new page, grab whatever POSTS you are sending in and new-up an Exception with whatever details you need. Immediate throw this exception. Doing this means that this exception will follow whatever flow other unhandled exceptions follow in the app (logging, emailing, etc).
3) On the page that calls the WebMethod JS, Wrap the calls to the WebMethod in a try-catch
4) In the catch block, print out whatever message you want in the browser, and initiate a new AJAX post to that new error receiving ASPX page, passing along whatever POST stuff you made that page look for.
The new AJAX call will NOT change ANYTHING in the user's perception by default. The AJAX call fires off a new request to that page, and the ASPX page itself is actually totally unaware that its AJAX and not a normal browser request. Any cookies/session/authentication data that's currently set are available to the AJAXed page as well, if you are recording a user's ID or anything. If you look at the returned response from a tool like Firebug, you will see that its actually the YellowScreenOfDeath's HTML (unless you have a custom 500 page, in which case its that HTML that comes back).
This is simply how the legacy ASMX web services work.
The only workaround is to stop using them (which you should do anyway, unless you're stuck with .NET 2.0). WCF doesn't have this problem.
I have a global error handler in Global.asax and am trying to display the exception information in a page called ErrorPage.aspx. I've read Microsoft's page about passing information between asp.net pages (http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx). I don't think any of these will work:
QueryString: I'm concerned that the length of the exception will
exceed the maximum length of the QueryString.
Post Information: The Global.asax page doesn't have any form fields.
Session State: Session state is not available in Global.asax
Public Values: I think this only works with .aspx pages
Control from Source Page: Global.asax can't have asp.net controls.
My current thought is that it would be logical to create an instance of the ErrorPage object and navigate to it (as you could do in a Windows Forms application), but I don't know how to do that or if it is possible in asp.net.
Ultimately, I'm looking for a way to display errors caught by a global error handler in a standard .aspx page. Any suggestions would be helpful.
What I would do:
Log exception information including stack trace in a log file,
Redirect to an ErrorPage with error code (regular http errorcodes + a generic 'unknown error' one + maybe some custom errors that make sense for the application) passed in query string parameter,
Display a predefined message for this error code.
There is little reason to display actual error messages to end users, more detailed error information not withstanding. If you want to display full information for debugging purposes, turn custom errors off in web.config
The problem
When I try to make a AJAX partial update request (using the UpdatePanel control) from the default page of an IIS7 web site, it fails- instead of returning the html to be updated, it returns the entire page, which then causes the MS AJAX Javascript to throw a parsing shit-fit.
The suspected cause
I have narrowed the cause down to two issues- making an AJAX request to the default page when I have a certain custom http module registered. A partial rendering request to http://localhost will fail, but a partial rendering request to http://localhost/default.aspx will work fine.
Also, If i remove the following line in my custom HttpModule:
_application.PreRequestHandlerExecute += OnPreRequestHandlerExecute;
The AJAX partial render will work correctly. Wierd huh?
Another wierd thing...
If I look at trace.axd, I can see that when a partial rendering request fails, two POST requests are logged for the one partial rendering request- one where the default.aspx page executes successfully (trace information such as page_load is logged) but no content is produced and a second that doesn't seem to actually execute (no trace information is logged) but produces content (HTTP_CONTENT_LENGTH is greater than 0).
Please help!
If anyone with a good knowledge of HTTP modules or the MS AJAX Http module could explain why this is occuring I would be very grateful. As it is, the obvious work arround is to just redirect to default.aspx if the request url is "/" but I would really like to understand why this is occurring.
First of all PreRequestHandlerExecute is exactly before HTTP handler executes.
Second for hosting websites with HttpModules under IIS7 it is better that we run website in integrated pipeline mode, and also we have to move HttpModules tag in web.config to system.webServer module section.
If for example you change the handler in PreRequestHandlerExecute like this:
void context_PreRequestHandlerExecute(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
HttpContext context = application.Context;
if( something-happened )
context.Handler = null;
}
The result would be exactly as you said.
Setting handler to any thing else but its default, means that ASP.Net is not responsible for current request.
Note that each request only can have one HttpHandler.
Essentially I want to be able to catch when a user lets their session timeout and then clicks on something that ends up causing an Async postback. I figured out that if I put this code in my Session_Start (in Global.asax) then I can catch a postback that occurred during a session timeout:
With HttpContext.Current
If TypeOf .Handler Is Page Then
Dim page As Page = CType(.Handler, Page)
If page IsNot Nothing AndAlso page.IsPostBack Then
'Session timeout
End If
End If
End With
This works fine. My question is, I would like to be able to inject some javascript into the Response and then call Response.End() so that the rest of the application does not get finish executing. The problem is that when I try Response.Write("<script ... ") followed by Response.End() then javascript does not get written to the response stream. I'm sure there are other places in the application that I can safely write Javascript to the Response but I can't let the rest of the application execute because it will error when it tries to access the session objects.
To sum up: I need to inject javascript into the response in the Session_Start event in Global.asax
Note: You may be wondering why I'm not doing this in Session_End...we don't use InProc sessions and so Session_End doesn't get called...but that's beside the point...just wanted to make it clear why I'm doing this in Session_Start.
Writing to the response stream outside of an HttpHandler is generally not a good idea; it may work in some corner cases, but it's not how things are intended to work.
Have you considered using either a Page base class or a Page Adapter to do this? That way, you would only need one copy of the code, and it could be applied to either all pages or just the ones you select.
Another option would be to use URL rewriting to redirect the incoming request to a page that generates the script output you need.
I have a custom security principal object which I set in the global.asax for the current thread and all is well, no problems normally.
However, I'm just adding a dynamic image feature by having a page serve up the image and whenever that dynamic image page is loaded the System.Web.HttpContext.Current.Session is null in global.asax which prevents me from setting the security principal as normal and cascading problems from that point onwards.
Normally the Session is null in global.asax only once during a session at the start when the user logs in, afterwards it's always available with this single exception.
The dynamic image page is loaded when the browser comes across an image tage in the original page i.e.
I'm guessing that this is some aspect of the fact that the browser is requesting that page without sending some credentials with it?
Any help would be greatly appreciated.
John,
I'm assuming you're using an ashx handler for the handler. If so, be sure to derive from IRequiresSessionState for example:
public class Images : IHttpHandler, System.Web.SessionState.IRequiresSessionState
{ }
If you're not using an ashx can you describe what you mean by dynamic image page?
Josh
in Global.asax.cs Session_Start() and Session_End() you need to use "this.Session" !!
The reason for this is that HttpContext is only available when there is a request that is being processed. That is why you are getting a NULL on HttpContext.Current.Session!
From Microsoft website:
"HttpContext Class: Encapsulates all HTTP-specific information about an individual HTTP request."
But don't feel bad ... i fell for this one too! :)
Session has nothing to do with being logged in or not.
What event are you overriding when you want access to the session? Session isn't available until AcquireRequestState has been fired.
For more information, see: http://msdn.microsoft.com/en-us/library/9ysfzy8h.aspx
yes you are right This happens because the object dependancy might conficts in case of other page transferance parallel which may break down the firewall between sessions