I'm using code in the Application_BeingRequest() handler of my Global.asax to do some very primitive URL Rewriting. That works fine, however, I'm having issues fetching the rewritten URL in JavaScript.
So using URL Rewriting www.mydomain.com/dothis becomes www.mydomain.com/?action=dothis on the server-side. Using ASP.Net and Request.QueryString["action"], I get the expected result of dothis. JavaScript, of course, still sees www.mydomain.com/dothis because that's what is displayed in the browser.
I don't suppose there is a way for JavaScript to see the actual page URL, even though it's not displayed in the address bar?
What happens on the server beyond the http interface is not visible to the UA if you don´t tell it explicitly.
The rewrite is happening on the server before the server forward the request to the appropriate handler.
You can tell the UA this in many ways (ask Tim Toady ^^). Hidden form control, a JavaScript variable to mention a few. This is ofc if your framework/server supports this.
Related
I have a standard html registration page that targets an external .asp page on submit.
What happens is that currently the .asp (which I don't have access to)returns an entire html page.
Instead I would like to somehow parse the returned html and populate the existing form with either
a) validation errors if incorrect
or
B) some sort of success message if all validated
Can anyone tell me if this is possible and or help with some pseudo code?
This is doable in JavaScript using ajax, but it requires that the ASP page (presumably on a different domain) sends appropriate CORS HTTP headers. Even if you don't have access to the actual ASP page, you may be able to get someone to setup the headers in IIS on their server.
Otherwise, you're stuck moving everything server-side, i.e. simulating the POST on your own webserver, and scraping the HTML to get the status back. That looks something like:
Postback the page to your own page (or use Ajax)
On your server, initiate a web request post of the data to the ASP page
Parse the results in your server code
Return an appropriate response to the browser client
The best you can do, assuming I'm interpreting your question correctly, is "scrape" the HTML returned from the asp page and make proper assumptions about the location and meaning of the text within the markup. I, personally, would strongly advise against developing anything of any kind of robustness based on what amounts to screen scraping, especially considering you don't have access to the .asp file itself. If I've misunderstood your problem, my apologies.
Regarding to a static link on a web page, the browser will issue GET or POST request to the web site, depending on whether a form of parameters attached.
However, I want the browser to issue a PUT request for that link, how can I do that? I know that Ajax could do it, but I don't want to use Ajax.
I want the browser to issue a PUT request for that link
it seems that PUT and DELETE are currently unsupported in html forms, according to this submission to the w3.
I know that Ajax could do it
Not always true. Because PUT and DELETE are at times unsupported by some browsers, ajax cannot consume them without making a dummy param to trigger a real PUT or DELETE server side, which gives the illusion of full HTTP support by ajax.
Is it possible to rewrite URL on the fly, only when a part of the server code has already been processed for the "raw" URL and it becomes clear the parameters must not be revealed to the user? Like, I want to proccess all the GET parameters in my page code on the server and create a tracking record in the database, then serve the user the page but change URL to parameterless in the browser.
I guess all the web.config referred module techniques won't work as they offer URL rewriting before request is passed to the page code on the server. But it comes in my case that I receive an ugly URL from google adwords clicks and I do like it tracked 'as is' in my database, and I do certainly not like it show to user in her brower's bar.
At the same time I would like to keep URL unchanged without applying the URL rewrite most of the time unless some particular parameter shows up in it (like ref=adwords) so that any paramter written by hand or posted back would be displayed in the address bar.
Is it possible to do so by any means?
Have you considered writing an ActionFilter that would (if your controller or method is decorated with it) intersect your initial request, do all the necessary processiong and then redirect back to the requested page only indicating, that processing has been done?
This would be my first thought.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.