Whats difference between Redirect() and RedirectPermanent(). I had read some articles, but I don't understand when we must use Redirect() and RedirectPermanent(). Can you show a pieces of example.
The basic difference between the two is that RedirectPermanent sends the browser an HTTP 301 (Moved Permanently) status code whereas Redirect will send an HTTP 302 status code.
Use RedirectPermanent if the resource has been moved permanently and will no longer be accessible in its previous location. Most browsers will cache this response and perform the redirect automatically without requesting the original resource again.
Use Redirect if the resource may be available in the same location (URL) in the future.
Example
Let's say that you have users in your system. You also have an option to delete existing users. Your website has a resource /user/{userid} that displays the details of a given user. If the user has been deleted, you must redirect to the /user/does-not-exist page. In this case:
If the user will never be restored again, you should use RedirectPermanent so the browser can go directly to /user/does-not-exist in subsequent requests even if the URL points to /user/{userid}.
If the user may be restored in the future, you should use a regular Redirect.
RedirectPermanent is 301 and Redirect is 302 status code
They send different response codes to the browser. 301 is a permanent redirect, 302 a temp one. The end effect is the same, but if the client wants to index links (the most common client that does this will be search engines) then a permanent redirect tells the client to update its records to ignore the old link and start using the new one. A temp redirect tells the client that the page is redirecting for now, but not to delete the old link from its indexing database
Related
I have a Ruby on Rails application which redirects users to the start or login page if they end up at a resource they are not authorized for.
For that, it redirects through a 302 Found.
This does not feel right to me, as for example a successful creation of a resource via POST also returns a 302, with the only difference being that it redirects to the created resource.
On the other hand, it does not seem possible to redirect a user without returning a 30X status code (401/403 in this case).
Am I missing something here, or am I already doing it correctly and this is just the way to go?
Well I'd say that it depends of the context, for an API I'd go for you way, if the user is trying to reach an endpoint without authentication or without enough permissions, I'd return a 401 or 403 respectively.
But for a web application without a separated frontend app, you've no choice to tell to the browser where it has to go next and the only way of doing this is to use redirections (that are only 3xx HTTP codes => https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages).
I have an app where I try to adhere to REST.
The app receives requests for external links that don't belong to the app, so the sole purpose of the action is to redirect the request to the external URL.
My suggestion is to have the following controller/action: redirects_controller#create.
Is my thinking correct or should it be the show action instead?
REST (apart from Rails) is about using the correct HTTP method for the correct action. The Rails part is just using the conventional controller action for a given HTTP method.
So, if you're doing a 301 or 302 redirect to another page, which browsers handle by issuing a GET request to the URL in the redirect response's Location header, do it in a show action. This will allow the user's browser to cache the other page when appropriate, and to not notify the user before redirecting.
(There is a way to redirect POSTs, but you didn't mention it so I expect you're talking about regular 301/302 redirects.)
Coming from a Java background, the REST actions must be related to CRUD operations. Requests that do not change the resource like in your case where the intent is to redirect to another page must be tied to a GET verb or show in your example.
If you were to create a new resource you would use POST.
A more detailed explanation can be found in Richardson's rest maturity model level 2
Given I use an CMS which makes an article available unter the following URL: http://example.com/article/1-my-first-and-famous-article/
Internally I can identify the requested article unequivocally by its id (1).
How should I handle requests to a wrong (typing error, manipulation, ..) URL? For example someone requests http://example.com/article/1-my-firsz-and-famous-article/ or http://example.com/article/1-this-article-is-stupid-idiot/ - should I respond with http status code 301 and redirect to the right URL or with 404 and show a not found page (maybe with redirection after a few seconds). Which is the preferable way in terms of search engine optimization?
Wrong URLs will be 404 error and any existing page moved to new location will be 301 redirect
I am wondering about the difference between 301 and 307 redirects.
I am looking to generate backlinks through a home-brew url redirector, and I wish for any of the "link juice" or "page rank juice" to flow directly from the originating back page through to the final URL, but if one of the originating back pages goes bad, I'd like to be able to shut that link off by deleting the redirect link for that particular page. Make sense?
My understanding is that 301's are permanent meaning that google will see the 301 and update its cached URL as the final destination, regardless of whether I kill off that redirect at a later time.
If I use a 307, it won't cache the destination URL and will keep checking the redirect URL to see where the back link actually points to, and if I kill off the redirect link, Google will no longer assign that back link to the destination URL.
Is this a correct summary?
It's correct. Actually 307 is variation of the more common 302 redirect
301 Moved Permanently This and all future requests should be directed
to the given URI.
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI;
however, future requests should still use the original URI.
I have a single ASP.NET MVC app which uses areas to deliver different functionality depending which url is hit. For example
www.domain.com - Website Area
app.domain.com - Application Area
*.domain.com - Client Area
So, the point is that depending on the incoming url, we route you to a different MVC Area. This is all done using Routing with some extensions and works great.
Now, if I enable outputcache on the Index() Action for my www default route, the next time i hit app.domain.com, i get the cached version of the www domain. I checked using fiddler and the response is a 200 OK so it's definately hitting the server. However, the logging in my custom routing tells me it's not hitting that code.
So, does OutputCache not work based off the uri and instead uses some other algorithm?
Thanks
[OutputCache(VaryByHeader="Host")] should help.
The behavior will depend on where you decided to store the cache (Location property). Ifv you stored the cache on the server (OutputCacheLocation.Server) then the result from the execution of the action will be stored on the server and when a subsequent request is made to this action, the server will be hit and it will directly return the cached version without executing the controller action which is the behavior you describe.
If you store the cache on the client (OutputCacheLocation.Client), then the cache will be kept on the client browser. In this case if a subsequent request is made to the same action, the client will no longer hit the server but will directly serve the page from its cache. And remember that if you hit F5 in your browser you will expire the cache for the given page, so the server will be hit.