Is there any difference between doing a "GET" request (type URL and Enter) compared to simply refreshing (CtrlR) the page?
No, it is not simply a get request, because on a page that you've POSTed to (from a separate form), the browser will confirm with you that you want to refresh the page because it is a POST request.
As for your question, you'll need to provide specifics for debugging purposes.
It is simply telling the browser to repeat the page load, which implies repeating the GET or POST request. Some browsers will inform the server that 304 (not-modified) is an acceptable response, and the server can reply with a 304 HTTP response to inform the browser that it's cached contents are valid
Most browsers ignore the Expires header if we do a "page refresh", yet respect it if we do a "url visit".
However, different browsers have their own way of differentiating "refresh" and "url visit", the only way to be sure is to manually test each one of them.
Related
I have been reading on SAML 2 binding mechanism. It says below :
HTTP REDIRECT VS. POST BINDINGS: Both SPs and IDPs can transmit and receive messages using redirect or POST bindings. Due to the limitation of URL lengths in certain scenarios, HTTP Redirect is usually used when passing short messages, and HTTP POST is used when passing longer messages.
I am unable to understand how a response with the same length can be longer in redirect than it is in post. I think I am missing something very basic. Could anyone help to clear that ?
Redirects utilize the querystring to pass data, which has a size limitation that is not present in a post.
From w3schools:
Example Get:
/test/demo_form.asp?name1=value1&name2=value2
Example Post:
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
the parameters for a get are located within the URL itself, which has a size limitation of 2083 characters (there is some variation to this number). For a post, the information to go along with the post is in the actual body of the message, rather than the URL.
Basically you get more "room" in a post, as you're not going to hit a size restriction on URL because your information is in the body - unless your URL is already that long which would mean it'd be an issue for gets or posts.
Why is the redirect url is of longer length?
I think you might be misunderstanding, it's saying you get less room for a redirect than a post, not more/longer. Gets have a size restrictions, posts do not, or at least it's a configurable setting on the server and has a larger "higher end" than a get request would.
If you visit an aspx web form, and click the submit button causing a POST to the server, then click submit again causing a second POST before receiving a response from the first POST, what happens in terms of the response? Does the server process both requests simultaneously or serially? Does the server send both responses? Does the browser ignore one of the responses? This may be self explanatory after an answer to the previous questions, but if I were to call Response.Clear(); Response.End(); for the second request, what would happen on the browser end?
If there are no special means at the server side to handle multiple POSTs, the server will handle both requests independently. Whether or not the processing is concurrent - it depends:
if your first POST causes the whole page to reload then it is impossible to trigger the second POST before the page is processed at the server side (because your second click is made from the page which is already at the client side)
if your first POST causes an AJAX POST to the server and the processing takes some time at the server then it is possible that you end up with two POSTS from the same page processed concurrently at the server side
The server always sends responses and browsers do not ignore them. It is your code, at the server side or at the client side, to prevent such unintended multiple POSTs, for example by 302ing the response to another location which doesn't allow the user to rePOST the form.
Specifically, if you just clear the response (send an empty content) and the content type is text/html then the browser will render an empty page.
I would say just about any of those things could happen, depending on the exact timing.
I believe calling Response.Clear(); Response.End(); on the second request would cause an empty response which the browser would receive, possibly after receiving the results of the first request.
Is this possible.. for example, imagine I respond to a request with a 302 (or 303), and I inform the browser to do a request to a given location.. is there a header that I can send with the HTTP 302, so that the subsequent request from the browser would include that header?
I know I could do this with the location header, as in redirect and specify the information in the url as a query string.. but I'm wondering if there is a better way.. it seems that it should be a legit scenario..
'Content has moved, go here .. oh and you'll want to take this with you to give to the redirect location'
I'm guessing a big fat no!
Thanks in advance.
Edit
The reason for this is in respect to PRG patterns, where you have a GET url and POST url, given that you post data and it isn't acceptable, the server redirects you to the GET, and does some 'magic' in order to 'send data' to that GET, using most often session state to store a variable.
However this can breakdown in scenarios where many of these PRG requests are happening, granted this isn't a common scenario and generally nobody need worry about this.. but if you do- you'll need a way to identify the requests, this can be done with query string parameters send in the 302.. so that a specific entry can be put in session state according to that request.
The question was regarding trying to remove the 'request key' from the url, and making it more implicit.. cookies 'appear' to work, but they only make the window for screw ups smaller.
It would be great to say when you go the 'location' i've specified, send these parameters.
Edit
Just to note, I'm not trying to get the browser to send arbitrary headers to the location, but if there is ANY headers designed to hint the context of the request (like the querystring parameters could).
A redirect response itself doesn't contain any data. You can redirect using a URL with query parameters, but the new "location" will need to know how to consume those parameters.
No, that’s not possible. You cannot force the client to something. You just can say “this is not the right location, but try that location instead”. But it’s not guaranteed that the client will send the same request or another request to that new location. And telling the client to add a specific header field in that subsequent request to the new location is also not possible.
I want the browser to reflect some other URL than the one used to create the request, but without roundtripping to the server.
I would maybe do this:
POST /form HTTP/1.1
...
...and then return:
HTTP/1.1 200 OK
Location: /hello
But that would cause a redirect, the browser will again, request URL /hello.
I would like to just tell the browser that, while the request you just sent was POST /some_url the actuall resource that I'm now returning is actually called GET /hello/1 but without preforming a roundtrip. i.e. Location: ...
Is there any way to do this with JavaScript or the base="" attribute? That will tell the browser to request /hello/1 when I hit F5 (refresh) instead of that, post submission warning?
HTTP/1.1 200 OK
Location: /hello
Actually that probably wouldn't work; it should be a 30x status rather than 200 (“303 See Other” is best for the response to a POST), and ‘Location’ should be a complete absolute URL.
(If your script just says ‘Location: /relativeurl’ without the 30x status, CGI servers will usually do an internal redirect by fetching the new URL and returning it without telling the browser anything funny happened. This may sound like what you want but it isn't really because from the browser's point of view it's no different from the original script returning a 200 and direct page.)
But that would cause a redirect, the browser will again, request URL /hello.
In practice that's probably not as bad as you think, thanks to HTTP/1.1 keep-alives. The client should be able to respond to the redirect straight away (in the next packet) as long as it's on the same server.
Is there any way [...] That will tell the browser to request /hello/1 when I hit F5 (refresh) instead of that, post submission warning?
Nope. Stick with the POST-Redirect-GET model for solving this.
No. Http is stateless, and every request has one answer. When you post, you need to redirect to a get page immediately to prevent a double post - you don't want it to sit on that post url. The redirect is what tells the browser that it is on a new page. That's just the way it works.
I am implementing a HttpRequestValidationException in my Application_Error Handler, and if possible, I want to display a custom message.
Now, I'm thinking about the StatusCode. In my current example, it sends a 200, which I think should not be done. I would like to send the (IMHO) more appropriate 400 Bad Request instead. However, at the same time, I would like to use Response.Write to enter a custom message. Firefox displays it properly, but IE7 gives me the Default unhelpful Internet Explorer Error Page.
On one side, I guess that Internet Explorer just assumes that everything <> 200 is simply not having any "good" content, and the RFC is not really clear here.
So I just wonder, is sending a HTTP 200 for an Error Page caused by a HttpRequestValidationException good practice or not? Are there good alternatives?
An HTTP 200 Response Code does not indicate an error. It indicates that everything was OK. You should not use a 200 response code for an error.
Internet Explorer shows its "Friendly Errors" page if the response is less than 512 bytes. Here's more on this issue: http://weblogs.asp.net/scottgu/archive/2006/04/09/442332.aspx,
No, it's certainly not a good practice. 2XX status codes mean (among other things) that the request is valid. Which is just the contrary to raising a HttpRequestValidationException.
I don't know how to make IE behave correctly, sadly. A slightly better way than to send a 200 would be to redirect it to an error page, but still far from perfect.
Internet Explorer shows what they call a "friendly HTTP error message" when the response is 4xx or 5xx. This option can be turned off by the user in IE's Tools.Options.Advanced[Browsing] dialog.
Sending a 200 for an error page is generally bad practice. One alternative would be to have a valid "Error" page that's supposed to show error messages (so a 200 would be okay) and then use a 3xx redirect to that page.