I am trying to set a custom header variable after doing a lookup in SQL Server and then redirect the user while still having access to the variable. I have tried:
Response.Addheader "custvar", customvariable
Response.Redirect("http://example.com")
But when I get to example.com the header is not present. Is there another way to do this? I am using IIS and have tried the simple ASP above so far.
I don't think it is possible to do it with header.
What Response.Redirect effectively does is it sends the 302 result (Found or Moved Temporarily) to a browser. Then browser makes another call to the address which was provided in 302 result. This means that you are creating a response header for 302 result, but this header has no way to be used in subsequent result to example.com.
If you want to pass some information between requests and request is made to the same site you could set a cookie and it will be sent during your redirect. If you control the site where you redirect to you can also use query string to pass the required parameters. Of course you should not add sensitive information to either cookie or query string.
I agree with #dotnetom. I use response.redirects with variables passed in query string very successfully throughout my application to achieve this result along with variable i wish to pass. Non sensitive data caveat of course also.
Add the custom header as per instructed here
adding custom header with classic asp
and then add the redirect manually without the re-direct
eg.
Response.Addheader "custvar", customvariable
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.thenewpage.com"
I'm trying to understand this properly.
I have a simple web form which, in the page load, I have a bit of code that creates a HttpWebRequest object. This then performs a Http POST passing some info in the body.
The response passes back a 302 redirect just fine. How would I redirect to the location page from the response in the page load? If I did a Response.Redirect would that being doing a HTTP GET again?
In addition, some of the info I pass in the post body will determine if I can even access the page that it wants to redirect. What's stopping someone getting the location URL and just pasting that in the browser and essentially doing a HTTP GET as well?
It is a little confusing and I may not be grasping it correctly and would love some insight.
How would I redirect to the location page from the response in the page load?
Sow the code that makes the request. You'll have to read the redirect location from the response and see MSDN: How to: Redirect Users to Another Page.
If I did a response.redirect would that being doing a get again?
Yes.
Whats stopping someone getting the location URL and just pasting that in the browser and essentially doing a get as well?
If you mean the "location" header from the 302 response to the POST you make in your Page_Load: your server will perform this POST request, not the client's browser. So they won't see this request or the URL it points to.
However, if you redirect them to the location the 302 response to the POST is pointing to, then their browser will go there anyway.
I would like to do a temporary redirect (307) on a page which accepts POST data. The page it is being redirected to does not need that data to be posted to it (the POST data is already processed on the initial landing which does the redirect).
Maybe it's new in Firefox, but it prompts the user with "This web page is being redirected to a new location. Would you like to resend the form data you have typed to the new location?". I would like to avoid that prompt, and explicitly state that the data does not need to be posted to the new URL.
Is there an HTTP header that would specify this?
The right response code is 303 (See Other).
Ah, I posted this too quickly.
The answer is to use a 302 redirect instead of a 307.
Apparently 307 keeps the request method, while 302 makes it a GET. I head just read the wiki for redirection here: http://en.wikipedia.org/wiki/URL_redirection, and it wasn't terribly clear on this point. It made it seem like 302 was just replaced by 307 for temporary redirection.
Is the client supposed to behave differently? How?
Status 301 means that the resource (page) is moved permanently to a new location. The client/browser should not attempt to request the original location but use the new location from now on.
Status 302 means that the resource is temporarily located somewhere else, and the client/browser should continue requesting the original url.
When a search engine spider finds 301 status code in the response header of a webpage, it understands that this webpage no longer exists, it searches for location header in response pick the new URL and replace the indexed URL with the new one and also transfer pagerank.
So search engine refreshes all indexed URL that no longer exist (301 found) with the new URL, this will retain your old webpage traffic, pagerank and divert it to the new one (you will not lose you traffic of old webpage).
Browser: if a browser finds 301 status code then it caches the mapping of the old URL with the new URL, the client/browser will not attempt to request the original location but use the new location from now on unless the cache is cleared.
When a search engine spider finds 302 status for a webpage, it will only redirect temporarily to the new location and crawl both of the pages. The old webpage URL still exists in the search engine database and it always attempts to request the old location and crawl it. The client/browser will still attempt to request the original location.
Read more about how to implement it in asp.net c# and what is the impact on search engines -
http://www.dotnetbull.com/2013/08/301-permanent-vs-302-temporary-status-code-aspnet-csharp-Implementation.html
Mostly 301 vs 302 is important for indexing in search engines, as their crawlers take this into account and transfer PageRank when using 301.
See Peter Lee's answer for more details.
301 redirects are cached indefinitely (at least by some browsers).
This means, if you set up a 301, visit that page, you not only get redirected, but that redirection gets cached.
When you visit that page again, your Browser* doesn't even bother to request that URL, it just goes to the cached redirection target.
The only way to undo a 301 for a visitor with that redirection in Cache, is re-redirecting back to the original URL**. In that case, the Browser will notice the loop, and finally really request the entered URL.
Obviously, that's not an option if you decided to 301 to facebook or any other resource you're not fully under control.
Unfortunately, many Hosting Providers offer a feature in their Admin Interface simply called "Redirection", which does a 301 redirect. If you're using this to temporarily redirect your domain to facebook as a coming soon page, you're basically screwed.
*at least Chrome and Firefox, according to How long do browsers cache HTTP 301s?. Just tried it with Chrome 45.
Edit: Safari 7.0.6 on Mac also caches, a browser restart didn't help (Link says that on Safari 5 on Windows it does help.)
**I tried javascript window.location = '', because it would be the solution which could be applied in most cases - it doesn't work. It results in an undetected infinite Loop. However, php header('Location: new.url') does break the loop
Bottom Line: only use 301s if you're absolutely sure you're never going to use that URL again. Usually never on the root dir (example.com/)
301 is that the requested resource has been assigned a new permanent URI and any future references to this resource should be done using one of the returned URIs.
302 is that the requested resource resides temporarily under a different URI.
Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests.
This response is only cachable if indicated by a Cache-Control or Expires header field.
The main issue with 301 is browser will cache the redirection even if you disabled the redirection from the server level.
It's always better to use 302 if you are enabling the redirection for a short maintenance window.
There have already been plenty of good answers, but none tells pitfalls or when to use one over the other from a plain browsers perspective.
Use 302 over a 301 HTTP Status whenever you need to keep dynamic server side control about the final URL. Using a 301 http status will make your browser always load the final URL from its own cache, without fetching anything of any previous URL (totally skipping the first time request). That may have unpredictable results in case you need to keep server side control about the redirected URL.
As an example, in case you need to do URL redirection on behalf of a users ip-geo-position (geo-ip-switching) use 302. If you would use a 301 in such a scenario, the final redirected page will always come directly from the browsers cache, giving incorrect/false content to the user.
301 is a permanent redirect, and 302 is a temporary redirect.
The browser is allowed to cache the 301 but 302 means it has to hit our system every time. assuming that we want to minimize the load on our system, 301 is the right decision. Imagine creating URL shortening service for a big company, we try to get as less hit to our servers by the clients
But if the user wants to edit their short URLs, it might take more time than usual for the browser to pick up the change because the browser has the old one cached. Also, if you want to offer users metrics on how often their URL is getting hit, 301 would mean we would not necessarily see every hit from the client. So if you want analytics as a feature later on and a smooth user experience for editing URLs, 302 is a better choice.
For logging purposes i want to log the redirect target of the current request to a database. how can i read the readirect target of the current request. keep in mind that i do not want to log on every Response.Redirect. I want the logging to take place in a central location. this location might be Application_EndRequest. I have tried to read the Repsonse.Headers collection to read the location header but is is not there.
In your Application_EndRequest event, you can read the following two properties on your Response object:
Response.StatusCode will be set to 302 on redirects.
Response.RedirectLocation will be set to the URL where the browser will be redirecting.
Can you "invert" problem?
I mean property HttpRequest.UrlReferrer - can expose where you came from, so you could filter pages where UrlReferrer = 'login page' and log them to DB