Asp.net pages using Response.Redirects

derbaff

Hello,
I am attempting to test a website which almost exclusively uses Reponse.Redirects to send the user to different pages. I have read all about the issues ANTS has with these, especially with login pages. I found a workaround on this forum that works perfectly for the login page on the web site, but then fails everywhere else. When the client logs in, a Reponse.Redirect is used to send it to the main page and WebClient.HttpRequest.Status correctly equals 302, at which point the script executes WebClient.Get(WebClient.HttpResponse.Location). This works fine, however, when the client encounters redirects elsewhere on the site, WebClient.HttpRequest.Status equals 200, not 302. I do not understand why. Also, WebClient.Get(WebClient.HttpResponse.Location) is null.

In my script I have the funciton:

    Private Sub redirect()
        Me.LogToFile("redirect " + WebClient.HttpResponse.Status.ToString())
        If (WebClient.HttpResponse.Status = 302) Then
            If (WebClient.HttpResponse.Location = Nothing) Then
                Me.ReportError("HttpResponse.Location is null")
            Else
                Me.LogToFile("Redirecting to " + WebClient.HttpResponse.Location.ToString())
                WebClient.Get(WebClient.HttpResponse.Location)
            End If
        End If
    End Sub

I call this function everytime the script posts to catch redirects. But it only works at the login screen.

I hope somebody can shed some light on this. Thank you.

BTW, I am using SSL and have applied the SSL patch.

Brian Donahue

Hello,

This is an interesting issue. Are the dynamic pages perhaps writing directly to the response stream rather than using redirects?

Is it possible for you to have a peek at the aspx code to find out?

derbaff

I do have access to the sourcecode and the pages are definately using Response.Redirect(). After running the script I end up with a log file that looks something like this:

Ants Trace Log created 07/21/2005 4:54:25 PM
VirtualClient 0 07/21/2005 4:54:25 PM
starting

VirtualClient 0 07/21/2005 4:54:25 PM
redirect 302

VirtualClient 0 07/21/2005 4:54:25 PM
Redirecting to /MyWebSite/Default.aspx

VirtualClient 0 07/21/2005 4:54:25 PM
redirect 200

VirtualClient 0 07/21/2005 4:54:26 PM
redirect 200

VirtualClient 0 07/21/2005 4:54:26 PM
redirect 200

VirtualClient 0 07/21/2005 4:54:37 PM
starting

VirtualClient 0 07/21/2005 4:54:37 PM
redirect 302

VirtualClient 0 07/21/2005 4:54:37 PM
Redirecting to /MyWebSite/Default.aspx

VirtualClient 0 07/21/2005 4:54:37 PM
redirect 200...

Only the first Reponse.Redirect() off of the login page seems to send down a 302. Almost all the navigation on the site relies redirects.

As I am writing this and looking at the logfile again, I noticed the value of WebClient.HttpResponse.Location is relative, not absolute. Could this be the problem...?[/code]

derbaff

As I am writing this and looking at the logfile again, I noticed the value of WebClient.HttpResponse.Location is relative, not absolute. Could this be the problem...?

I tested this theory by prepending an absolute reference to WebClient.HttpResponse.Location, and now the script makes it 2 pages deep before I start getting invaid viewstate exceptions on the website. My logfile indicates that a 302 is being received after the first to posts, after that I keep getting 200's again. The only difference I see between the 2 pages that work and rest are on the first 2 pages, Response.Redirect() is called in the event handler of a button, on the rest of the site it is being called in the event handler of an Infragistics menu. Though I don't see why this would make a difference. I am still very confused.

Brian Donahue

Hello,

Yes, on every installation of IIS I'd ever tested ANTS Load on, the location header returns a relative URL, so normally you need to prepend the server name before the path returned in the Location header.

Now the challenge seems to be the viewstate problems. Can you please check that the pages are requested in the proper order? If, for instance, you have a GET and POST request for the same aspx page, then a request for another aspx page somewhere in the middle will cause that page's viewstate to be sent as part of the POST to the first page, and the viewstate will be invalid.