In Classic ASP, how do you detect on that the page got control via a Server.Transfer()?
I cannot compare the URL vs the current ASP filename because the code is stored in a library (included).
You can check if Request.ServerVariables("URL") matches the current page. For a Server.Transfer the URL is still the original page that was requested.
In response to your edit: The page needs to provide the current page name to the code in the library, otherwise the library has nothing that it can compare the requested URL to.
There is no way to acheive this without some assistance from the page calling Transfer or the page to which execution is transfered. Probably the latter would be the best place to do this and tweak the library code to accept details from it about the transfer (if any).
Related
Using: Visual Studio 2010 with ASP.net 4.0
I have a website which uses URL rewriting and I want to keep the rewritten URL on Postback. I've read a lot of the topics on this subject and I still haven't been able to figure out if this is possible.
For example:
http://localhost/ActualPage.aspx?PageID=4
Is rewritten as:
http://localhost/member/forum.aspx
The page contains a number of controls which use a Postback (for example a Telerik RadGrid with sorting and paging). Normally when the postback takes place the browser is redirected to the unrewritten url - the address bar shows /ActualPage.aspx?PageID=4 etc. In this scenario everything works correctly.
However I want to retain the rewritten URL after the postback, so I have coded to change the Form.Action property to be the rewritten URL like so:
Page.Form.Action = "/member/forum.aspx"
Now the page correctly retains the URL in the address bar but throws a "Validation of viewstate MAC failed" error when the postback occurs - which I would expect it too as the viewstate originated from a different URL.
Strangely this problem occurs even when enableViewStateMac is set to false (either in the page or in the web.config) - but I don't want to disable this anyway.
Effectively I think what I need to do is tell the page / viewstate mac authorisation that is it ok to accept input from this alternative URL but I can't find anyway of doing this. I've tried different URL rewrite system to see if that makes a difference, and i've tried added a generated machineKey - neither of which has made any difference. Is there any way of doing this?
In short I want:
Rewritten page with postback going to the rewritten URL
ViewStateMac enabled
No viewstate validation errors
I remember in earlier versions of .NET using a .browser file with FormRewriterControlAdapter but this doesn't seem to make any difference in .NET 4 (I don't remember if it successfully retained the URL anyway).
I have found a solution - it turns out the problem was actually unrelated and masking itself as a ViewStateMac issue.
Previously I had been redirecting all the URLs to one page, doing a database lookup and then using Server.Transfer() to deliver the correct page to the browser. The real problem was being caused by using Server.Transfer() - which it seems is recognised by Microsoft to be an issue when working with the viewstate.
I have made adjustments so IIS performs the database lookup, the entire rewrite and therefore Server.Transfer() is not used - and the original problem I had has been resolved.
we are creating a custom content management and out portal page is bit bulky it is about 60Kb without images.
and during loading the page in some browser we can see some parts of site load faster than the other parts of the site where as we want to indicate (or instruct the web server) to load some of the areas first then load rest of the page.
is there any particulat setting in IIS for is there any particular method in classic asp for doing that?
also I have the same question in asp.net.
best regards.
I don't believe there is a built in way to describe which parts of a page load first in either ASP or ASP.Net. It really isn't a server decision - depends on how your browser parses the page and then requests the additional resources (or renders the existing ones).
You could potentially use AJAX and build in the order each section loads either as a state engine or by chaining. Seems to be pretty complicated for the benefit.
If you just don't want the user to see anything until the entire page loads you can control that from code using buffering. In classic ASP you use Response.Buffer and Response.Flush so the server doesn't start returning HTML until the whole page is ready - it will keep parts of the page from loading (the server won't stream results). I assume ASP.Net has a similar/identical method for buffering. Note that you can't pick sections of code with buffering but you can send only portions (top down) at a time.
I'm using the old 404-rewrite method on a certain site that is tied to IIS6 *.
So if I enter
http://example.com/non-existent/path
it calls my error page like so
http://example.com/catch.aspx?404;http://example.com/non-existent/path
Great.
Except if I call the page with a fragment, like
http://example.com/non-existent/path#with-fragment
I get the same result as above. I can't find the fragment anywhere:
Request.Url
Request.Url.OriginalString
Request.UrlReferrer
Request.RawUrl
headers, server variables, etc
This has come up because I want to resolve paths created by AJAX to their server-side versions.
Is there any way for me to retrieve the original path from my handler?
Thanks.
(*) Please don't suggest I change platform. Obviously I would if I could.
No, there isn't.
The portion of URL after # is never passed to the server per HTTP spec. Has nothing to do with platform.
To work with info after # in javascript you should look at Javascript History plugins/functionality. jQuery has history plugin, asp.net ajax and mvc ajax (partial views et al) have that. Mind you, it's not a very easy thing to implement, you have to get into undo/redo mindset.
It probably won't work if you are trying to handle 404's on the server - server doesn't know that there was something after #. Not sure what you want to do though, 404 handling, or "resolve paths created by AJAX"? What exactly is the goal?
I am building a website, within a large intranet, that wraps and adds functionality to another site within the same intranet. I do not have access to the other site's source and they do not provide any api's for the functionality they provide. I need to, somehow, have my server-side code go to that site, fill in some forms, then press a submit button.
Is this possible? If so, how can I accomplish this?
Note: I am working in asp.NET if that matters at all.
Not the most efficient, but maybe WatiN can get you started:
http://watin.sourceforge.net/
Just look at the URL the form is supposed to submit to and the method it employs (POST or GET) and then send a request to that URL using the same method and put the field you want as parameters
Your server-side code is basically a web client to the other web site. You will need to write the code to send the HTML form data to the other web site and process the response. I would start with the System.Net.WebClient class. Take a look at System.Net.WebClient.UploadValues. That class/method will enable you to POST the form data to the web site via a NameValueCollection.
Is there a way to share the session between ASP3 And ASP.NET?
Thanks
Despite all of Microsoft's best efforts to make ASP and ASP.NET coexist effortlessly, one area remains a stumbling block... session state. Fortunately the advantages of ASP.NET's upgraded session state management far outweigh the inconvenience of not being able to pass "Classic" session information to .NET. Unfortunately there is no simple solution; the most I can offer is an easy to implement workaround.
In trying to find a suitable resolution, I've come across two good options that are worth mentioning. The first involves parsing the session information out to hidden form fields on a "Classic" intermediate page and then submitting the page to a .NET intermediate page that loads the form fields into the session state. This is a good, simple solution, however it doesn't work both ways. In .NET you cannot specify the page that you submit to. Each page has to PostBack to itself.
The second option is probably closer to an actual solution than to a workaround. Billy Yuen at Microsoft has developed an effective solution. The code is elegant, the integration appears to be seamless, but I couldn't get it to work on my system (remember I said that there was no simple solution, not that there was no solution at all). If this solution works for you, great! You won't need my code and you'll be happily passing session information from "Classic" to .NET like it's going out of vogue, thanks for stopping by.
Ok, if you're still reading let me briefly describe the workaround I've created. It requires a database, but it is not important which type of database (though the code is written for SQL Server). When a page (source page) wants to redirect to another page (destination page) that uses a different version of ASP, it calls an intermediate page. The source intermediate page takes each session variable and adds it to the database along with a Globally Unique ID (GUID). Since "Classic" and .NET use different SessionID formats it is not possible to use SessionID, hence the use of a GUID. The source intermediate page then passes the GUID to the destination intermediate page through a Querystring variable. The destination intermediate page retrieves the session information from the database, cleans up after itself, and then redirects to the destination page. It's similar to the first workaround, but supports transferring state in both directions.
Code Usage
Installation
Run the SQL Query in "ASPSessionState.sql" on the database which will hold the temporary Session information.
Copy the .asp and .aspx.* (SessionTransfer.aspx and SessionTransfer.aspx.cs) files to a folder on your website.
Update connection object information in the "SessionTransfer.asp" and "SessionTransfer.aspx.cs" files. It is located in three places in each file (sorry about not consolidating the connection info).
Compile the aspx files.
The .asp and .aspx.* files must all reside in the same folder to work.
Usage
For use in a Hyperlink (Anchor Tag) or a Response.Redirect, set the destination URL to be one of the following:
From a ASP "Classic" page:
SessionTransfer.asp?dir=2aspx&url=<asp_dotnet_url>
From an ASP.NET page:
SessionTransfer.aspx?dir=2asp&url=<asp_classic_url>
The code will transfer the Session information and Redirect the user to the url specified by or .
Download
You can download the code from here: session_transfer.zip (4.6 KB).
Could take a look at NSession it allows sharing session state between Classic ASP and ASP.Net using State server. Pretty easy to setup just configure App to use State Server for session and register a couple of dll files.