Ultimately I have to send form post data from an iPad app to a simple ASP.NET page. Before I do that I just want to get the basic ASP.NET page working by sending a simple form post from an HTML page I have directly to the asp.net page. I post the html form to the asp.net page, and the Request.Form object is always null. I know the page is being hit, because the debugger stops on my breakpoints in the codebehind (.cs).
I know that if I sent the form post from the .aspx page it would work; that's the traditional asp.net form post model. But if the page won't process a post from an arbitrary html page then I believe it will also fail when the post comes from the ipad.
This is puzzling to me. Does ASP.NET somehow discriminate on form posts? Does it somehow know that the post didn't originate from its own aspx, and ignore the post? What is going on and how do I solve this? Thanks in advance.
Yes, ASP.NET does discriminate on form POSTs. If you set up an ASP.NET form normally and then use a tool such as Fiddler to see exactly what is being posted, then you will see all the hidden fields and values that ASP.NET requires for that page. Then, you'll be ready to send data from a non-ASP.NET source.
I'm using asp.net 4. Every control on a page has its viewstate turned off and in the HTML output, the viewstate looks like this:
< input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwULLTEwNDk4OTMyNTZkZGfL5BMyxxloFnGh0LG4Z2Wef3pPOstqLKsp8DrWelqn" />
When I run this string in a Base64 decoder I see that it's equal to -1049893256. This number changes on every page and every request.
The only controls I'm using are essentially literals; the page is in a master page.
What could this be field represent?
When using webforms, you can never truly turn viewstate off. Just ignore it.
I'd highly suggest you look into the various MVC engines available for asp.net. Those might be more to your liking.
You can delete the the tag of the form from the page,then view the page,the viewstate disappear in the page
second,use template engine,
The best explanation I've found for a postBack is from Wiki.
a postback is an HTTP POST to the same page that the form is on.
While the article does explain how a second page was needed in ASP, but no longer needed in ASP.NET, it doesn't give much detail or background. I am looking for a freakin' tome of information on PostBacks. Much like the simple question of "how can I clean a house" can be addressed by this 900 page book. I don't need 900 pages worth, but details please. I found a nice little tutorial for ASP.NET life cycle, but it seriously glosses over postbacks (amongst other things).
I am looking to the developers who have been around before .NET and really don't take these kinds of things for granted. Books and hyperlinks are reasonable answers or additions to your answer.
So far I've seen the right answer alluded to repeatedly, and almost everyone has come shy of what I consider subjectively to be the mark.
Let's start with the basics:
An HTTP request can be any of the HTTP verbs, but the two that people use most are GET and POST. Well, those are the two a programmer uses most frequently. The others all have some purpose, if they're implemented on the server. When you send information to the server, you can do so either through the use of the URL (to request a page) or within the body of the request (POST, PUT, DELETE, for instance).
Now you'll remark (I'm sure) that the URL in a GET request often contains data, and this is true, but according to W3C, you should not use GET to alter state, and yet we do often. It's sort of a hack that we all agree is an actual use, and not a hack. Whether that makes it a hack or an actual implementation detail I leave up to you.
So when you send the body of the POST (skipping the others for now, you can figure it out from here) with the form elements, you're sending back certain elements. How those elements are defined is up to you and to the environment you're working in. You could post to a server with a JSON element in the body, or with XML, or with form fields. Generally we do posts from a FORM element in the body of the HTML.
Now everyone says, "oh, a postback is a subsequent request to a page." But, that's not true. A postback is when you send data via POST -> back to the server. I say this because the difference between a GET request and a POST request is if data is included in the body (and the verb used, but the client usually knows how to deal with that). You could postback to the page on the first time the page is visited, and in fact ASP.NET has tools for doing that in the library. You could certainly have a desktop client POST data to a server (think Twitter) without showing any webpage at all from the server (ok, so twitter is probably not the best concept to use for an example here, but I want to illustrate that you can use a client that doesn't show the webpage, so no request is necessary).
So really what you should read there in "postback" is "I'm POSTing data BACK to the server for processing". It's presumed that you retrieved the page initially with a GET to show the user the <form> element that has <input> fields for them to interact with, and that at the end you're sending data back. But I hope you can see that it doesn't have to be in that order.
So here's something else to consider:
What if you gave the user a page with a bunch of <input>s and no <form> but instead, had a button wired up in javascript to concat all those <input>s with &value-n= and send them as a GET? Does the same thing, but violates that concept of only using GET for requests. (possibly) ensuing discussion encourages me to reinforce that GET should have no side effects (no updating values)
It's how come you can send someone a link to a google search, for instance. So we don't ALWAYS have to POST BACK to the server to get data.
Hope this helps.
Cheers
See ASP.NET Page Life Cycle Overview on MSDN for a good general introduction about what happens when a requests hits the server.
A PostBack is any request for a page that is not the first request. A PostBack will always be in response to a user action (triggered most commonly by a Button, AutoPostBack control or Ajax).
POSTBACK: Part of ASP.NET's contrived technique for hiding the true stateless nature of the web/HTTP behind a stateful facade. This results in complex code (IsPostback, ...), a hard to understand page lifecycle, many different events, ... and numerous problems (ViewState size, web-farm stickyness, state servers, browser warnings (not using PRG pattern), ...)
See ASP.NET MVC instead.
A post back is round trip from the client (Browser) to the server and then back to the client.
This enables you page to go through the asp engine on the server and any dynamic content to be updated.
here is a nice explanation
ASP.Net uses a new concept (well, new compared to asp... it's antiquated now) of ViewState to maintain the state of your asp.net controls. What does this mean? In a nutshell, if you type something into a textbox or select a dropdown from a dropdownlist, it will remember the values when you click on a button. Old asp would force you to write code to remember these values.
This is useful when if a user encounters an error. Instead of the programmer having to deal with remembering to re-populate each web control, the asp.net viewstate does this for you automatically. It's also useful because now the code behind can access the values of these controls on your asp.net web form with intellisense.
As for posting to the same page, yes, a "submit" button will post to an event handler on the code behind of the page. It's up to the event handler in the code behind to redirect to a different page if needs be (or serve up an error message to your page or whatever else you might need to do).
The Wikipedia definition of postback is pretty good, but I'd add the following:
A postback is a subsequent HTTP POST to the same page that the form is on.
If I have a page with a form on it and, rather than having my Submit button redirect the browser to another page that will process the form, instead have the Submit button refresh the current page (and perform some specific steps to validate/save the page, presumably), then that Submit button is said to have posted back to the current page.
Postbacks can be either full (refresh the entire page) or partial (in a case where AJAX is employed). A partial page postback will re-render only a part of the page (like a single drop-down list, a table, etc.).
In the old HTML, the only way to make something updated on the webpage is to resend a new webpage to the client browser. That's what ASP used to do, you have to do this thing call a "PostBack" to send an updated page to the client.
In ASP .NET, you don't have to resend the entire webpage. You can now use AJAX, or other ASP.NET controls such that you don't have to resend the entire webpage.
If you visit some old website, you would notice that once you click something, the entire page has to be refresh, this is the old ASP. In most of the modern website, you will notice your browser doesn't have to refresh the entire page, it only updates the part of the content that needs to be updated. For example, in Stackoverflow, you see the page update only the content, not the entire webpage.
Simply put this by a little code. Hope it is helpful to you.
When you firstly request the page url. you can view the source code of it in most browser. Below is a sample of it .
The essential of Post Back is actually call the __doPostBack which submit all the form data got from your firstly requested back to the server. (__EVENTTARGET contains the id of the control.)
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
NHibernate Demo
</title>
<script language="javascript" type="text/javascript">
function dopost() {
__doPostBack('LinkButton1', '');
}
</script>
</head>
<body>
<h1>NHibernate Demo</h1>
<form name="ctl01" method="post" action="Default.aspx" id="ctl01">
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTMxNzcwNTYyMWRkKHoXAC3dty39nROvcj1ZHqZ5FYY=" />
</div>
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['ctl01'];
if (!theForm) {
theForm = document.ctl01;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
//]]>
</script>
<div>
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="B2D7F301" />
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKZx5vTCgKM54rGBgLM9PumD20dn9KQguomfpAOdTG0r9Psa7al" />
</div>
<a id="LinkButton1" href="javascript:__doPostBack('LinkButton1','')">LinkButton</a>
<input type="button" value="testPostBack" id="testpostback" onclick="dopost();" />
</form>
</body>
</html>
Postback is a request during which ASP restores values of controls' properties from view state.
I am working on a page where we have a form that the user is filling some information in. When the form is submitted I want to process the information and then redirect to an external server. The catch is that I need post data to go to the external server so a redirect will not work.
Is there a way to programmatically submit a form request with post data?
For the sake of a ridiculous example let's say on http://A.com I have an asp.net page with two inputs that accept numbers and a submit button. When the button is clicked I want to send a post to http://B.com with a post data parameter "AdditionTotal" which contains the sum of the two numbers entered.
Absolutely, and it's very easy to do.
Normally a page posts back to itself, but you can override this by changing the "PostBackUrl" property of an ASP.NET button.
<asp:Button
ID="Button1"
PostBackUrl="http://B.com/AdditionTest.aspx"
runat="server"
Text="Submit" />
What you can do is something similar to what you're already doing (ie in your responst to Damien). However, put the data in hidden fields, and then submit the form via javascript on the onload. I know it's not very elegant, but if you need to post the data to the other URL, that's the only way you can get the browser to post the data.
You could post the data yourself, but there is no way to translate that back to the users browser to send them to it as well. Posts have to happen client side for the browser to display the response page.
I need to supply an html form (not a server form) for searching within an asp.net web-forms website. The form will post to another website where an indexed search is performed. Seeing as nested forms don't work well in asp.net, what is the simplest approach for this?
The nested form is a simple html form that performs a "get" against the search website, which I do not have programmatic control over.
Update: I resolved my issue by simply moving the server form to the appropriate place on the page, rather than having it surround the entire page. However, I'm still wondering how this would be handled if the html form needed to be placed physically between server controls (which require the server form).
However, I'm still wondering how this would be handled if the html form needed to be placed physically between server controls (which require the server form).
You can place controls on your page without requiring an HtmlForm.
In your case there's no issue declaring another form markup, but you could also just use some search control on your main form and make it issue a GET to that website.
Not only do nested forms "not work well," you basically can't have >1 form per page at all. The simplest approach is the approach you are forced to go with: write a page that only uses one <form runat="server"></form>. Since you need search functionality, is there no ASP.NET search box control that you could use?
Have a read here.
There are 4 workarounds:
Use an IFRAME
Force Submission to Navigate Using a GET Request
Dynamically Change the Form Action
Use a 3rd Party Form Handler
More details on http://www.revindex.com/Blogs/tabid/65/EntryID/21/Default.aspx
Nested forms don't work well in HTML full stop! You should never do it.
Perhaps you mean more than one form on page? Whilst it's true you can only have one form with runat="server", I can't see any reason why you couldn't have a standard form (not server form) that posted to another site at the same level (ie. not nested).
Try adding your HTML input elements to wherever you want the nested form to be. Then use JQuery to change the page form action to point to the external Website. The entire form is submitted, but with a different external Url. The minor downside is the values for all input elements on the page are posted, but most times that is not big deal.
(I only tried this using a POST, not a GET. This is basically Roman O's #3 workaround in more detail)
<div id="nested-form">
<input type="text" name="q">
<input name="searchbtn" value="Go" type="submit" class="search-button">
</div>
<script>
$(function() {
$("input.search-button").click(function() {
$('form').get(0).setAttribute('action', 'http://external.com');
});
});
</script>
maybe you try Server.Transfer() to your target page that do the search from a button for example!