preserving querystring in 404 customer error page

querystring not preserved when custom 404.asp used

[stipo]

I am moving our site up one directory from www.xyz.com/v4/ to just www.xyz.com and want to use a custom 404.asp page to redirect the visitor to the new page, minus the /v4/. Everything works fine except where the original page has a querystring. I find that my 404 custom error page is not passing the original querystring to the redirected page.

For example, if a visitor arrives via this URL, 'www.xyx.com/v4/product.asp?sku=123', they end up at 'www.xyz.com/product.asp?sku=123' So it's all the same except for the v4/ being removed. My custom page redirects to 'www.xyz.com/product.asp' without the original querystring sku=123.

Hope someone can help,

Cheers

[mattglet]

In your 404 page, you are going to need to capture the original query string. You will either need to parse it out manually, or use Request.ServerVariables("QUERY_STRING"), depending on your 404 setup.

-Matt

[stipo]

Hi Matt,

I've used Request.ServerVariables("QUERY_STRING") in an attempt to get the querystring from the original request but it just gives me the original request without its query string. It gives me 'www.xyx.com/v4/product.asp' instead of 'www.xyx.com/v4/product.asp?sku=123'.

Cheers,

Michael

[mattglet]

Ok, I'm going to assume this is happening because 'www.xyz.com/product.asp' is actually the querystring on your 404 page. You are going to have to manually parse out the correct values.

Use of the split() & mid() functions are probably going to be in your future.

-Matt

[streetshirts]

I use this code to do something similar: To keep the querystring when redirecting. I've never used it in error page, but I don't know why it wouldn't work.

qs = Request.querystring()

Response.redirect("your_target_page.asp?" & qs )

[john_k]

The structure of the querystring that is passed into the 404 error handler is not the same as for standard pages. It has this format:

404;http://www.xyz.com/v/product.asp?sku=123

So in your case, you could split on the "?" character.

sQS = Split(Request.QueryString, "?") 
If UBound(sQS) > 0 Then 
 Response.Redirect "http://www.xyz.com/product.asp?" & sQS(1) 
Else 
 ' Bad request 
End If 

[stipo]

Hi John,

Thanks for the tip. I tried that but I can't get it to work. I think my problem is that the query string of the original request is not being passed by IIS5 to my 404.asp at all.

When I go to [myserver...]

I end up at

[myserver...]

The querystring is therefore the 404;.... and the original '?sku=123' has gone. It's as if IIS doesn't like haveing two?'s.

Cheers,

Michael

[stipo]

PS,

I've tried my 404.asp script on our IIS 6 server and it works there. Must be something to do with IIS 5.

On our IIS 6 server response.write request.querystring gives me '404;http://myserver:80/product.asp?sku=123' but on our IIS 5 server it gives me '404;http://myserver/product.asp' without the '?sku=123' that I need.

I might have to move to IIS 6 sooner than later if I can't get it work in IIS 5. Any ideas?

Thanks for your help.

[john_k]

Must be something to do with IIS 5

That is odd. IIS 5 should provide the original querystring as well. I have several sites running on IIS 5 that utilize this method.

[dataguy]

I have several large sites that parse out the querystring from 404 errors to display dynamically generated 'ghost' pages, all running IIS 5.

About a month ago I was building a new site and I went through IIS, first setting up the custom 404 location and then disabling the components that weren't needed in the new web site. This was a very basic web site, so I disabled almost all the components in the "Application Configuration" page. When I went back to the site, I noticed that the 404 error page no longer received the querystring associated with the original URL.

I checked and rechecked my code and verified it was the same code that was working properly on another site, then I decided it must be a result of the configuration changes that I made.

Looking at another functioning site, I set up the dll's on the new site in the same way, one by one, until it started working properly again, but for the life of me I can't remember what dll or extension that did the trick.

If all else fails you can always start over and create a new site with the default settings. Hope this helps.