I have a page where a user submits an order, and after they submit it, I want to hit a url (http://externalsite.com?id=12345&sessionid=abc123
) without actually redirecting them to the external page.
Is there a way to do this?
I have a page where a user submits an order, and after they submit it, I want to hit a url (http://externalsite.com?id=12345&sessionid=abc123
) without actually redirecting them to the external page.
Is there a way to do this?
Sure, use an HttpWebRequest
from your server-side code. Here's an example:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(
"http://externalsite.com?id=12345&sessionid=abc123");
request.Method = "GET";
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
using (StreamReader reader = new StreamReader(response.GetResponseStream()))
{
string result = reader.ReadToEnd();
// Process the response text if you need to...
}
If you need the user's cookies (login details and other user settings) on http://externalsite.com/
, you can embed an <iframe>
or a faked image or use an ajax request from the user's browser.
Using an <iframe>
:
<iframe src="http://externalsite.com?id=12345&sessionid=abc123" width="1" height="1" frameborder="0"></iframe>
Using a "faked" image request (if you can ignore any potential image type problems):
<img src="http://externalsite.com?id=12345&sessionid=abc123" width="1" height="1" />
Using jQuery's cross-browser ajax support in its simplest form:
$.ajax({
url: "http://externalsite.com?id=12345&sessionid=abc123"
});
You can also apply additional formatting to hide the iframe or image, or remove it using javascript when it has served its purpose of hitting the other server.
Combining two of the answers above, from voithos and Joel Purra, I suggest you consider a third alternative as well. Below is my assessment of each:
1) The more assured way of hitting the site is to do it server-side as part of your action-handler for the actual submission of the user's information. That can be easily done through voithos' method above:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(
"http://externalsite.com?id=12345&sessionid=abc123");
request.Method = "GET";
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
using (StreamReader reader = new StreamReader(response.GetResponseStream()))
{
string result = reader.ReadToEnd();
// Process the response text if you need to...
}
This allows your server to hit their server and ensure that it gets called. The downside to this approach is that it makes YOUR server have the overhead of the secondary HTTP request. If the other server is slow, this could create a blocking issue which would create apparent slowness on your end. You can get around this by going multi-threaded/async - but you get the picture: it introduces a bunch of problems to solve that are outside your control - BUT - it ensures that you know whether or not the remote source was hit, and what the reply was.
2) Alternatively, if your user is making an actual post and getting back an HTML response as a new page, you could simply inject Joel Purra's response into that resultant page's HTML, forcing the user's browser to be responsible to hit the remote server.
<div style="display: none;">
<iframe src="http://externalsite.com?id=12345&sessionid=abc123"></iframe>
</div>
The downside of this approach is that if for whatever reason your client fires off the request and doesn't wait for the next page to load, the external site returns a 404 error, etc., not only will the external processing not get done - you won't know that it didn't get done.
3) If you have the ability to use a client-side library such as jQuery to do your processing, I would suggest that you have all of the form submission happen in-line and asynchronously. The approach would be something like this:
<script type="text/javascript">
$(document).bind('ready', function () {
$('#formSubmitButton').bind('click', function (ev) {
ev.preventDefault(); // These two lines stop the default processing from
ev.stopPropagation(); // occurring on form-submit (i.e. no full post-back)
// This line starts an asynchronous call to the server, posting your form
// data itself.
$.ajax({
url: '/My/Post/Url',
type: 'POST',
async: false,
// You could use a library for this kind of form parsing. I suggest
// http://www.json.org/js.html - for serialization, and
// http://code.google.com/p/form2js/ - for form conversion. It's great.
data: { my: 'form', data: 'fields' },
success: function (data) {
$.ajax({
url: '/The/External/Url',
type: 'POST',
async: false,
data: { external: 'data', goes: 'here' },
success: function (remoteData) {
if (remoteData) // validate response here
displaySuccess();
else
displayFailure();
},
error: displayFailure
});
},
error: displayFailure
});
});
});
</script>
In this method - you do the post to your own server, and on success - immediately fire off a second request to the remote server. However, because you wait to display success/failure to the user until after the second request has already been fired - you know that at least at the UI layer, both requests have been made before the client gets a queue to leave the page.
So - perhaps safer from a work-flow and overhead perspective - however, it requires you to write some UI level logic in JavaScript, which could be problematic, depending on your project.