Context.Rewrite path following Querystring access

[Matt Howeson]

Some time ago I posted a request for help with a problem I was having
sometime ago whereby a 404 error would result if any access to the
Querystring had been made before the Context.Rewrite path is called.
(http://groups.google.co.uk/groups?hl...&threadm=66a19
d98.0212240627. 3f123293%40post ing.google.com)

I have recently received a number of emails from people asking if I ever
found a solution, so I thought I'd post what I have done to work around this
problem. I am not saying this is the right solution but it works, and it
solved a huge headache for me.

private System.Collecti ons.Hashtable LocalQuerystrin g;

public void Application_Beg inRequest(objec t sender, EventArgs e) {
//cast sender into instance of HttpApplication class
HttpApplication application = (HttpApplicatio n)sender;

// retrieve requested Url
string requestedUrl = application.Req uest.Url.ToStri ng();

// get all querystring data
int qsPos = requestedUrl.In dexOf("?");

// Again not sure if this is the best way of doing this
if(qsPos > -1) {
qs = requestedUrl.Su bstring(qsPos+1 );
} else {
qs = "";
}
LocalQuerystrin g = LoadQueryString (qs);

// You can now access any querystring variable using the following
syntax
// LocalQuerystrin g["version"}.ToSt ring()
// This would return the value of the version querystring parameter,
without having to use
// the Request.Queryst ring object, the below rewritepath should now work
as planned!
// now do required rewritePath redirect
Context.Rewrite Path("template. aspx?pagename=" +
application.Ser ver.UrlEncode(R equest.Path));
}

// Loads all of the parameters passed in the querystring into Hashtable and
returns this Hashtable
private System.Collecti ons.Hashtable LoadQueryString (string qs) {
System.Collecti ons.Hashtable qsHash = new
System.Collecti ons.Hashtable() ;
string[] qsArr = qs.Split("&".To CharArray());

foreach(string s in qsArr) {
string[] item = s.Split("=".ToC harArray());
try {
qsHash.Add(item[0].ToString(), item[1].ToString());
} catch(System.Ex ception ex) {}
}
return qsHash;
}

Hope the above helps someone out.

On a similar note, one of the other issues we have experienced with this
methodology is that when the page is served the form action uses the the
rewritten path, not the requested url. This means that viewstate data
cannot be loaded and causes an error. To overcome this we output a
javascript function with every page that overwrites the action attribute of
the form with the correct value, i.e. the originally requested path. This
enable the viewstate to be loaded correctly.

Has anyone else out there found a better solution for the above problem? I
hate having to use Javascript to perform this task as it is far less
reliable than actually having the correct action output with the page. Is
there a way to override the rendering of the webform action attribute?

Any help appreciated.

Thanks,

Matt Howeson
http://www.3internet.com
Please take a look at our Inigo Content Management System on our website.
C#, Asp.net driven wysiwyg content management.