I'm working on an asp.net web app. One of my web page received a posted value from a remote server:
HiddenField1.Value = Request.Form.Get("something")
And further on I'm using javascript to manipulate value from this HiddenField1.
The weird thing's that if I clicked on the "reload this page" icon on any browser:
reload page icon
page's reloaded and HiddenField's value's there
However if I moved mouse to the address area and clicked on the url,
address area examplethe url string's background turned blue and I hit Enter key,looked like the page's behavior's exactly the same: reloaded. However, the HiddenField's value's gone.
Any hint what's the difference between the two scenario?
This is not strictly related to ASP.Net: it is actually a common browser behavior and you would experience the same with a different server language (php, python or whatever).
In your second scenario, the browser will send a new (GET) request to the server, asking for the last loaded URL. It would be the same if you just type the address starting from a blank Address area.
In the first case instead, you are telling your browser "please, repeat the last request you made". Maybe it was a POST request sending data (form fields) to the server, and the server did answer to the previous request inserting the hidden field you are noticing.
To recap, the second scenario is "send a GET request for this address, ignore everything else". The first is "Repeat the last request you send. If it was a POST request with form data, send it again as the time before"
Very likely in your case, the server code inserts the hidden field just in case of a particular POST request (possibly according to posted data), and not for a GET request
If you don't know the difference between POST and GET for an HTTP request, this answer can be helpful
Related
I was given a task to solve a bug on some old project that someone else wrote.
The project is ASP.Net deployed on IIS.
Scenario:
Open Request form.
Fill personal details.
Click button "Add Items" to open items selection window.
Select items and close the item selection windows.
Expected:
Back in Request form, it is now showing both the personal details, entered in
step 2 and now, on the same request page, the list of selected items, selected in step 4.
Actual:
Back in request form, not showing personal details and only showing
the selected items.
From the code I learn that every field on the request form is:
Saved to the session (E.g onChange in JavaScript call code-behind save
function)
Load from the session on Page_Load
I guess the above is needed as a replacment machanism for the ViewState,
because in the above scenario it is required for the form fields (E.g personal
details) to persist across several pages. (The opening of other windows
to add items...)
Also from the code I learn that items added on "Add Items" windows are:
Saved to the session in the page "Add Items"
Loaded from the session in the Page_Load of page "Request"
Now instead of working on the project over at the customer's offices we copied
the project and deployed it back in our offices - only problem is now it is
working fine - that is, both the personal details and the list of selected
items are showing as expected.
I would like any suggestions... What could be the cause of such
behavior?
Also in case I will not be able to recreate the problem on my environment,
what should I check/debug on the customer's office?
...What could be the cause of such behavior?
Based on your symptoms, it sounds like could be happening is the server is relying on a client-side script (to set the form values sent down from the server's response) that has a dependency (e.g. jQuery) that might not be supported by the (possibly outdated) browser being used.
...what should I check/debug on the customer's office?
Here is what I gather is supposed to be happening after the client has the form open:
User enters values in form control(s). ("Personal Details")
Client-side event handler sends asychronous requests to the server (no callback) in order to save form values to the user's Session.
User clicks a button. ("Add Items")
Client-side event handler opens a new window that sends a request to the server for the "Items Selection" page.
Response is received from the server and the "Items Selection" page is displayed on the client.
User selects values for controls. ("Items Selection")
User clicks a button ("Close Window")
Client-side event handler:
Sends a request (with the "Items Selection" values) on behalf of the previous window to the server for the "Personal Details" page.
Closes the current window.
Previous window receives response, page reloads completely, and all form data is still present (reloaded).
We know at the very least 9. isn't actually happening properly, since this is your stated problem.
Assuming I have your implementation correct, you should start by determining how the values are supposed to be written to the controls during the last step (e.g. server controls' values assigned directly or server registers start-up client-script to write the form values). Then you should check the values that are sent to the method you discovered. If the values are incorrect, keep backing up to each previous server request to see what is the resulting Session state before the response. If the values are correct then you know something is going wrong (most-likely client-side) after the client receives the response from the server (I think this should only happen if my jQuery theory above is correct).
Some users who navigate to my page do so via an url like this : http://domain/ProductDetail.aspx?Productid=123#Pricing
In this section is a asp:button to make a purchase. This button cause a postback, and when the page rerendering in the broswer the FragmentIdentifier #Pricing is still in the address window.
This is causing problems because there is new content rendered on the page which isn't visible if the browser navigates to the #Pricing section.
How do I prevent the FragmentIdentifier on postback?
Clarification:
It appears that this problem happens in Chrome but does not happen in IE8 or FireFox. Chrome holds on to the #FragmentIdentifier after postback even those there is no reference to it in the action attribute.
You can't, browser doesn't send it:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted by the user agent after the
retrieval action has been successfully completed. As such, it is not
part of a URI, but is often used in conjunction with a URI.
How to get Url Hash (#) from server side
Browsers don't send URL fragments on the server side. You can't modify them the only option you can try is URL rewrite, if that helps. good luck...
The ASP.NET engine will cause a simple submit without any given URL, so the browser is forced to take the URL of the current page.
You can get rid of the hash after the postback by hooking a self executing javascript into the HTML that will replace the hash to an empty string.
Here is an example:
if(this.Page.IsPostback)
{
this.Page.ClientScript.RegisterStartupScript(this.GetType(), "RemoveHash", "window.location.hash=''", true);
}
You can force the browser to get rid of the # tag by redirecting to the same page.
My application disables caching on the browser via responses headers and then uses the Post-Redirect-Get pattern to enable the back button to "re-Get" the current page.
However on retesting this now with Firefox 12 and IE 8 I'm not seeing the results I was expecting (or that I had seen before with IE 6).
Upon selecting the back button I can see that the browser is attempting to perform the original request (the Post), not the redirected request (the Get). When I look at the requests on the network tab of Firebug I see the following:
Looks like the browser is treating the Post and Get as the same request and hence selecting the back button is re-submitting the Post:
I am using JSF, but I think this is a browser issue. Does anyone know why the browser is not performing a get of the redirected page?
It's working fine. The back button re-executes the request before "POST accountDetails.xhtml" which is not listed in your 1st screenshot, but is according the 2nd screenshot apparently (and logically) a "GET accountDetails.xhtml". You're apparently in the bean associated with that view or in some filter doing some checks and redirecting to "registrationWelcome.xhtml". The "POST accountDetails.xhtml" in the 1st screenshot is the current request which has been redirected to "reviewInfo.xhtml".
The back button does not re-execute the redirect. It's your own code which did it. The back button does also not re-execute the POST request, which is confirmed in the 2nd screenshot.
My question is - what is the difference between page refresh (if I press f5) and postback (If I press a button)?
Can anyone please tell me?
Thanks in advance.
A refresh mean a complete reload of the page, without any form data. This is essentially an HTTP GET.
A post back is when the page is posted to itself (through the form action=""). This is essentially an HTTP POST.
Lets have the actual difference between refresh and explicitily submitting a page :
1) Refresh does not mean to post back the page with get method..(You can check it with response.write request.form("some input type")).
2)Difference lies with the data sent to the server :
in case of explicit submit form is submitted with latest value(i.e it recognize the changes in form elements)
But in case of refresh, form is submitted with default form value.(i.e if you change the value of form element it will not reflect at server.)
when page is refresh that means page is sending request to server without any data that means HTTP GET but in another case suppose a event is fired that causes postback after
page completely load on browser if we press f5 or do refresh then it will send privious data with request instance, that means again for that data server will perform operation...
have u seen somtimes while you are doing online sopping after selecting item and press accepet button uyou get total price ,now again if you refresh then for that selected item it will again go to server that means you are buying same things twice.....i think now you get everything what i want to say...
in when page is postback then code of that page again compile and also processing `request data`. this process will going on
Or vice versa.
Update:
Hmm, let's assume I have a shopping cart app, the user clicks on the Checkout button.
The next thing I want to do is send the user to a Invoice.aspx page (or similar). When the user hits checkout, I could Button.PostBackURL = "Invoice.aspx"
or I could do
Server.Transfer("Invoice.aspx")
(I also changed the title since the method is called Transfer and not TransferURL)
Server.TransferURL will not result
in a roundtrip of HTTP
request/response. The address bar
will not update, as far as the
browser knows it has received only
one document. Server.Transfer also retains execution context, so the script "keeps going" as opposed to "starts anew".
PostbackURL ensures an
HTTP request, resulting in a
possibly different URL and of course
incurring network latency costs.
Usually when you are attempting to "decide between the two" it means you are better off using PostbackURL.
Feel free to expand your question with specifics and we can look at your precise needs.
Here is a good breakdown between the two:
Server.Transfer vs Response.Redirect
Server.Transfer is done entirely from the server. Postback is initiated from the client for posting form contents and postback url identifies the page to post to.
Maybe you meant to compare with Response.Redirect, which forces the client to submit a new request for a new url.