Why is it that ASP/ASP.NET Response.Redirect uses a HTTP-302 status code ("Moved Temporarily") even though in most cases a HTTP-301 status code ("Moved Permanently") would be more appropriate?
Responses with status 301 are supposed to be cacheable, and I don't think you want that behavior for most ASP/ASP.NET redirects.
ASP.NET 4.0 is has the RedirectPermanent method for that if needed.
I've used this handy Permanent Redirect with success:
public void RedirectPermanent(string newPath)
{
HttpContext.Current.Response.Clear();
HttpContext.Current.Response.Status = "301 Moved Permanently";
HttpContext.Current.Response.AddHeader("Location", newPath);
HttpContext.Current.Response.End();
}
One common use case of Response.Redirect is to move the user to another page in server-side code after a postback, e.g. something along the lines of
private void MyButton_Click(object sender, EventArgs e)
{
if (some condition) {
Response.Redirect("ShowProduct.aspx");
} else {
Response.Redirect("SorryOutOfStock.aspx");
}
}
In those cases, 301 would be completely wrong. In fact, I think that the above case (conditionally move the user to another page after some UI interaction) is a much more common use of Response.Redirectthan a real this-page-moved-to-another-URL-forever scenario (where a return code of 301 would be appropriate).
In addition to the answer from Heinzi, the only entity on the web that is likely to take much notice of the 301 would be the search engines. Most browsers will not track and record 301 in order automatically redirect any subsequent request for the initial URL. Browsers treat 301 identically to how they treat 302. Hence 302 in dynamic content such as generated in ASP.NET is quite appropriate.
The error you are getting is not due to response.redirect !
The HTTP response status code 301 Moved Permanently is used for permanent redirection, meaning current links or records using the URL that the 301 Moved Permanently response is received for should be updated to the new URL provided in the Location field of the response.
Related
If I redirect a page using Response.RedirectLocation ="login.aspx" then how it is different form Responce.Redirect("~/login.aspx")?
Thanks
Response.Redirect(url); Causes a 302 redirect (A temporary redirect) and closes the response causing the user browser to be redirected to the alternative URL.
If you want to permanently update a URL, for example you have made changes in the URL structure and you wish to let the world know that this is a permanent change (ie. search engines to pass on the ranking from the old URL to the new), then this should be indicated via a 301 Permanent Redirect.
This can be done as follows:
Response.Status = "301 Permanent Redirect";
Response.StatusCode = 301;
Response.RedirectLocation = "http://newurl.com/";
Response.End();
Note: Response.RedirectLocation does not stop processing of preceding code (unlike Response.Redirect()). This means that unless you want to continue processing tasks, you need to close the connection.
To summarise:
Response.Redirect() always causes a 302 temporary redirect, and halts processing
Response.RedirectLocation allows more control, for example setting the correct status codes, or continue further processing if required.
RedirectLocation sets the Location HTTP header. Redirect does so much more and completes the response with a 3xx status code.
I recently came across a Chrome issue which I think is worth sharing it with you.
I worked on a self written API using an HttpHandler which primary should return json data. But when an error occures I wanted to display an html file. That worked pretty well in IE and FF, but not in Chrome.
Looking to the developer tools revealed this error: net::ERR_INCOMPLETE_CHUNKED_ENCODING
Google said not very much about this issue while it was seen very much. All I got to know was, that it was magically disappearing after some time.
I found out it lays on this lines of code:
result.StoreResult(context);
context.Response.Flush();
context.Response.Close(); //<-- this causes the error
After removing the last line it worked well. I don´t know why only Chrome had/has an issue with that, but it seemed as if I closed the response stream before chrome finished reading it.
I hope it helps those of you coming across the same or a similar issue.
Now my question:
How is the best pratice in closing/flushing the response stream? Are there any rules?
According to ASP.NET sets the transfer encoding as chunked on premature flushing the Response:
ASP.NET transfers the data to the client in chunked encoding (Transfer-Encoding: chunked), if you prematurely flush the Response stream for the Http request and the Content-Length header for the Response is not explicitly set by you.
Solution: You need to explicitly set the Content-Length header for the Response to prevent ASP.NET from chunking the response on flushing.
Here's the C# code that I used for preventing ASP.NET from chunking the response by setting the required header:
protected void writeJsonData (string s) {
HttpContext context=this.Context;
HttpResponse response=context.Response;
context.Response.ContentType = "text/json";
byte[] b = response.ContentEncoding.GetBytes(s);
response.AddHeader("Content-Length", b.Length.ToString());
response.BinaryWrite(b);
try
{
this.Context.Response.Flush();
this.Context.Response.Close();
}
catch (Exception) { }
}
I was running into this error when generating a file and pushing it to the user for download, but only occasionally. When it didn't fail, the file was consistently 2 bytes short. Close() forcibly closes the connection, whether it's finished or not, and in my case it was not. Leaving it out, as suggested in the question, meant the resulting file contained both the generated content as well as the HTML for the entire page.
The solution here was replacing
context.Response.Flush();
context.Response.Close();
with
context.Response.End();
which does the same, but without cutting the transaction short.
In my case, the problem was cache-related and was happening when doing a CORS request.
Forcing the response header Cache-Control to no-cache resolved my issue:
[ using Symfony HttpFoundation component ]
<?php
$response->headers->add(array(
'Cache-Control' => 'no-cache'
));
I was also getting same error. This issue was with web server user permission on cache folder.
On the offchance that someone is landing here as a result of issues with their ASP.net Core project, I was able to resolve by adding the IIS middleware.
This is done by adding UseIISIntegration when instantiating your webhost instance.
Once I had the same problem and the main reason was lying in my controller return type.
If you try to return a C# object just as-is, you will only get net::ERR_INCOMPLETE_CHUNKED_ENCODING so don't forget to serialize your complex objects before sending them out for java script client (or View).
i.e. my controller return type was :
public async Task<List<ComplexModel>> GetComplexModelList(){
return new List<ComplexModel>()
}
Which caused INCOMPLETE_CHUNKED_ENCODING error, so I tried to fix my mistake with something like:
using Newtonsoft.Json;
...
public async Task<string> GetComplexModelList(){
return JsonConvert.SerializeObject(new List<ComplexModel>())
}
I've got a page that checks if a user is logged in or the file is public then pushes a PDF to the browser via Response.WriteFile.
Works great except when Google indexes a file and then we remove the file. So I'm looking at adding a 410 Gone to the Response.Status and then redirecting to our error.aspx page.
Firebug tells me that it gets a "302 Found" status code on the document page when a file is deleted. I'm expecting a 410.
Redirect code is:
Response.Status = "410 Gone";
Response.AddHeader("Location", Request.Url.ToString());
Response.Redirect("error.aspx");
Could someone please tell me what I'm getting wrong please?
Redirection is done by sending a status that indicates that the resource is available somewhere else, such as 301 Moved Permanently or 302 Found. You can't send two status codes in the same response. Either the requested resource does not exist (so you send 410) or it does exist at some other location (so you send 301 or 302 or whatever).
I don't think you should be redirecting to an error page, though, because an error message isn't a separate resource that should have its own URL. If a client requests a file and the file is gone, send a 410 Gone status with the error message as the response body — that way the error message comes back from the URL of the nonexistent file itself. A search engine will see the status code and understand that the file is gone, and a browser will show the response body to the user so he can read the error message.
If you look at the spec for 410 Gone, it states that "no forwarding address is known", so a redirect does not seem valid. You can return that same body on that response that you would from error.aspx if you want human users to see something.
The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be
considered permanent. Clients with link editing capabilities SHOULD
delete references to the Request-URI after user approval. If the
server does not know, or has no facility to determine, whether or not
the condition is permanent, the status code 404 (Not Found) SHOULD be
used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the
discretion of the server owner.
You can also use this way, first change your desire status.
Response.Status = "410 Gone";
Response.AddHeader("Location", Request.Url.ToString());
ScriptManager.RegisterStartupScript(this, this.GetType(), "redirectScript", "window.location.href=error.aspx", true);`
So, in that you get your desire page and status as well.
This is how I had to do a 301 moved permantently response. It should be similar
//in Global.asax.cs
protected virtual void Application_BeginRequest (Object sender, EventArgs e)
{
if(Request.Url.Host=="www.earlz.biz.tm" || Request.Url.Host=="earlz.biz.tm" || Request.Url.Host=="www.lastyearswishes.com"){
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location","http://lastyearswishes.com"+Request.Url.PathAndQuery);
CompleteRequest(); //I believe this is the missing piece in your code.
}
}
I have been solving similar issue. If the page with resource is removed from the web, I woul like to tell Google Bot 410 Gone, remove from cache, but I would like to offer an alternative similar page to the visitor.
I have solved it like this:
public ActionResult RealEstate(int id, string title)
{
...prepare the model
if (realEstateModel.Result.OfferState == OfferState.Deleted)
{
var alternativeSearchResult = PrepareAlternative(realEstateModel);
return Gone410(alternativeSearchResult, context);
}
else
return View(realEstateModel);
}
Gone410.cshtml look slike this:
#model Bla.ModelGone410
#{
Layout = null;
Html.RenderAction("Index", "Search",
new
{
type = Model.type,
Category = Model.Category,
city_id = Model.city_id,
...
});
}
and RealEstate.cshtml:
#model Bla.realEstateModel
#{
Layout = null;
}
This is realestate view...
This gives the response 410 to google bot and search alternative for the user with no redirect.
I know this question has been answered before in this thread, but I couldn't seem to find the details.
In my scenario, I am building a console application which will keep an eye on html page source for any changes. If any update/change occurs, I will perform further operations. Moreover, I'll also perform a request after every 1 second, or as soon as the previous request finishes.
I can't seem to figure out should I use HttpWebRequest or WebClient for downloading the html page source and perform comparison? What do you think would be an ideal solution in my case? Speed and reliability both :)
I'd go with HttpWebRequst because it's not as abstracted and lets you fiddle with HTTP params quite a bit. It gives you the option to not download the entire page if the server returns "file not changed", for example.
If you add some parameters to your request like IfModifiedSince (it might be HEAD or GET request) the server may return the response code 304 - NOT MODIFIED. Refer to description of caching in HTTP for further explanation.
The point is to make sure that you only download the full page when it's actually modified since the last time you fetched it. Most of the time it won't be changed (I suppose, can't know for sure without knowing your domain), so you only need to get a lightweight response from server which simply states "nothing changed here".
Update: code sample demonstrating the use of IfModifiedSince property:
bool IsResourceModified(string url, DateTime dateTime) {
try {
var request = (HttpWebRequest)HttpWebRequest.Create(new Uri(url));
request.IfModifiedSince = dateTime;
request.Method = "HEAD";
var response = (HttpWebResponse)request.GetResponse();
return true;
}
catch(WebException ex) {
if(ex.Status != WebExceptionStatus.ProtocolError)
throw;
var response = (HttpWebResponse)ex.Response;
if(response.StatusCode != HttpStatusCode.NotModified)
throw;
return false;
}
}
This method should return true if the page was modifed since the dateTime date and false if it wasn't. GetResponse method will throw a WebException if you make a HEAD-request and the server returns 304 - NOT MODIFIED (which is kinda unfortunate). We have to make sure that it's not some other web connection problem, that's why I check the status of web exception and the HTTP status in response. If anything else caused an exception we just throw it further.
Console.WriteLine(IsResourceModified("http://example.com", new DateTime(2009)));
Console.WriteLine(IsResourceModified("http://example.com", DateTime.Now));
This sample code produces the output:
True
False
Note: make sure to read Jim Mischel's addition to this answer as he gives few good advices on this technique.
I was going to leave this as a comment to #Dyppl's response, but it became too long.
Dyppl's response is generally good advice, and the way that I would approach this problem. However, there are a few things you should keep in mind.
First, there's no reason to do a HEAD request, followed by a GET if the page has been modified. You can do a GET with the IfModifiedSince header set, and the server will either return the entire page or a 304. Doing the HEAD first, followed by the 'GET`, ends up making two requests to the server, which defeats much of the purpose of the conditional request.
Second, you should set the IfModifiedSince property to the LastModified value returned by the previous response (i.e. HttpWebResponse.LastModified) because the server's time might not be synchronized with your computer. Also, I've found that a large percentage of sites, particularly those with generated content (like WordPress blogs) lie. They always return the current date/time in the LastModified header. As a result, there is no benefit to doing the If-Modified-Since check on those sites.
If you know that the site lies and always returns the current date/time, you can keep track of the ContentLength header that's returned from the page when you download it. Then, when you want to check to see if the page has changed, do a HEAD request and check the returned ContentLength header with the saved value. If they match, then it's unlikely that the page has changed. If they don't match, then do a GET request to update your copy of the page and keep the new ContentLength.
This technique does have the disadvantage of requiring two requests if the page has changed. It's also not 100% reliable on all servers. Some will return a different ContentLength for the HEAD request, and some don't return a valid ContentLength at all. That said, I've found it to be effective for a large number of sites.
I am trying to read the HTML of a page that contains a non-delayed redirect. The following snippet (C#) will give me the destination/redirected page, not the initial one I need to see:
using System.Net;
using System.Text;
public class SomeClass {
public static void Main() {
byte[] data = new WebClient().DownloadData("http://SomeUrl.com");
System.Console.WriteLine(Encoding.ASCII.GetString(data));
}
}
Is there a way to get the HTML of a redirecting page? (I prefer .NET but a snippet in Java or Python would be fine too. Thx!)
Unless the redirect is done on the client side you can't. If the redirect is done server side, then no html is actually generated to the client, but the header is redirected at the new server.
It would take more work, but rather than using WebClient, use HttpWebRequest and set the AllowAutoRedirect property to False. A redirect will then throw an exception, but you can get any response text (and some pages do have response text along with the redirect) from the exception's response object. After you get the response from the exception, you can issue another HttpWebRequest for the redirect URL (specified in the Location response header).
You might be able to do something similar with WebRequest if you create a derived object, MyWebRequest, where you overload the GetWebRequest method and set the AllowAutoRedirect property. I don't know what kind of exception, if any, the DownloadData method will return if you do something like that.
As somebody said previously, this will only work for those pages that do client-side redirects (typically 301 or 302). If there is server-side redirection going on, you'd never know it.
Simplest answer would be to add the current page onto the QueryString component of the redirect when redirecting, for instance:
Response.Redirect(newPage + "?FromPage=" + Request.Url);
Then the new page could see where you cane from by simply looking at Request.QueryString("FromPage").
If you want to get the source of an html page you can use this tool:
http://www.selfseo.com/html_source_view.php