friendfeed.com uses 302.
bit.ly uses 301.
I had decided to use 303.
Do they behave differently in terms of support by browsers ?
It depends on your purpose.
301 says “this isn't the proper URL, look elsewhere and use remember that other URL is better; don't come back here!”.
302 says “this is the proper URL which you should carry on using, but to actually get the content look elsewhere”.
303 is like 302 but specifically for redirections after a form submission.
If your purpose is a URL shortener then 303 isn't really relevant. It'll still work, but offers nothing over the normal 302. For a URL shortener I'd say 301 would be most suitable, as the other URL is the ‘real’ one. Saying 302 is trying to keep the ownership of the address and any SEO momentum caused by its use for yourself: a bit rude, but maybe you want to be rude.
Different status codes have different meanings. The HTTP specification describes them: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
301 — moved permanently (and change an
302 — found here
303 — find your response here, but use GET even if you started out with POST
If we take, for example, an Atom feed that has the URL changed for some reason (perhaps it is being moved to Amazon S3 or something). Given a 301 result, the feed reader should note that the feed has moved and update it's subscription. Given a 302, it will get the feed from its new location, but hit the original server looking for the original URI every time it checks for an update. (And a 303 would be silly in this situation).
Read http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for the answer.
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
Have a look at the HTTP 1.1 Status Code definitions. Different status codes imply different meanings and, therefore, encourage different behavior. Try to use the code which best matches your use case.
301 is for a permanent redirect and if this is what you want to do then this is recommended by all SEO experts.
"A 301 redirect is a permanent redirect that passes full link equity (ranking power) to the redirected page. 301 refers to the HTTP status code for this type of redirect. In most instances, the 301 redirect is the best method for implementing redirects on a website."
https://moz.com/learn/seo/redirection#:~:text=A%20301%20redirect%20is%20a,implementing%20redirects%20on%20a%20website.
Related
I have implemented SEO URLs using Apache 301 redirects to a 'redirect.cfm' in the root of the website which handles all URL building and content delivering.
Post data is lost during a 301 redirect.
Unable to find a solution so far, have tried excluding post method from rewrites - worst case scenario we could use the old type URLs for post methods.
Is there something that can be done?
Thanks
Using a 307 should be exactly what you want
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.[2] In contrast to how 302 was historically implemented,
the request method is not allowed to be changed when reissuing the original request. For
instance, a POST request should be repeated using another POST request
- Wikipedia
Update circa 2021
The original answer here was written before 307 status code redirect worked consistently across browsers. As per Hashbrown's answer below, the 307 status code should be used.
Old Answer
POST data is discarded on redirect as a client will perform a GET request to the URL specified by the 301. Period.
The only option is to convert the POST parameters to GET parameters and tack them onto the end of the URL you're redirecting to. This cannot be done in a .htaccess file rewrite.
One option is to catch POST requests to the url to be redirected and pass it off to a page to handle the redirect. You'd need to do the transposition of the parameters in code then issue the redirect header with the parameter appended new url that way.
Update: As pointed out in the comments to this answer, if you do redirect to another URL specifying POST parameters and that URL is also accessed without paramters (or the params are variable), you should specify a link to the canonical URL for the page.
Say the POST form redirects transposed to the following GET resource:
http://www.example.com/finalpage.php?form_data_1=123&form_data_2=666
You would add this link record to the head section of the page:
<link rel="canonical" href="http://www.example.com/finalpage.php" />
This would ensure all SEO value would be given to http://www.example.com/finalpage.php and avoid possible issues with duplicate content.
Using 301 redirects for general URL rewriting is not the way to go.
This is a performance issue (especially for mobile, but also in general), since it doubles the number of requests for your page.
Think about using a URL rewriting tool like Tuckey's URLrewriteFilter or apache mod_rewrite.
What Ray said is all true, this is just an additional comment on your general approach.
Is there such a thing?
A way it might be used:
Many locations have forms that post to http://www.example.com/wally/app/receiver.aspx
Managements decides they want a cleaner URL and there is no reason to pretend you are using aspx (you didn't really think I was using aspx for that did you?)
They say it should be http://example.com/receiver
Easy enough! Just put a 301 redirect. No need to update all those forms that exist all over..,, but wait.. You can't do that for POST.
Perhaps you can receive and handle the request and then re-write the URL without causing a subsequent request? Perhaps this will not strip the www (cross domain), but can it shorten the pathname like that without a separate request?
Even in GET requests, this would indeed be a performance boost if one could re-write the URL and send the response body at the same. Can this be done?
You cannot send content to user and do 301/302 etc redirect at the same time -- browser interprets the HTTP Response code and acts accordingly to the code received. If 301/302 -- it will do redirect, if 200 -- will display it to the customer.
Is there such thing as a HTTP URL re-write without 301 or 302 redirect?
Yes -- it's called rewrite (internal redirect). For example -- customer requests http://example.com/receiver. You rewrite URL to point to /wally/app/receiver.aspx (e.g. RewriteRule ^receiver$ /wally/app/receiver.aspx [L] -- that's if you have an Apache, which you most likely not (considering receiver.aspx)). This will do internal redirect when URL remains unchanged in browser address bar (works fine with POST and GET methods).
Well, I guess rewriting url suggested by LazyOne is not the answer to the question as he himself states that
This will do internal redirect when URL remains unchanged in browser
address bar
(http://www.example.com/wally/app/receiver.aspx). Still, the question asks for
(...) it should be http://example.com/receiver
I think the solution is to redirect old url to the new one using 307 status code introduced in RFC 2616. User agents which handle version 1.1 of HTTP protocol (I guess all popular browsers for some time now) should make the new request using the same http method (POST in this case) as in the original request.
Well this one freaks me out.
I used a Http Header check tool to check the headers of my webpage and guess what.
In every request the response was 302 instead of 200.
domain.con
www.domain.con
http://www.domain.con
So, am i missing something here?
I have not placed any redirect in any way.
So where the f#$% my website redirects? Is there a security hole?
UPDATE: While googling found this one
domain.com is not the same as www.domain.com - that's a redirect.
You are getting this because .net/IIS redirects your www.domain.com or domain.com to www.domain.com/default.aspx, so you get a header with 302 and then one for 200. I think this is by design but very confusing.
Maybe a case of this:
302 Found
This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, the majority of Web applications and frameworks still use the 302 status code as if it were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using a GET method. When received in response to a PUT, it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
It's possible that you forgot to add a final slash to the end of your URL. Most webservers will redirect you to the "canonical" location that includes the slash. If you include the slash, you may get the response you're looking for.
Are you using forms authentication? and log in page is some other page than the default page say auth.aspx? If this is the case then you will allways get 302 code and the page will be redirected to login page.
In ASP.Net we can redirect by using Response.Redirect & Server.Transfer.
If we go with server.Transfer the status code 302 will never hit & directly hits the 200.
If we go with Response.Redirect it passes from 302 to 200 as response.. Which is nothing but roundtrip.
Suppose I have a page on my website to show media releases for the current month
http://www.mysite.com/mediareleases.aspx
And for reasons which it's mundane to go into*, this page MUST be given a query string with the current day of the month in order to produce this list:
http://www.mysite.com/mediareleases.aspx?prevDays=18
As such I need to redirect clients requesting http://www.mysite.com/mediareleases.aspx to http://www.mysite.com/mediareleases.aspx?prevDays=whateverDayOfTheMonthItIs
My question is, if I want google to index the page without the query parameter, should I use status code 302 or 307 to perform the redirect?
Both indicate that the page has "temporarily" moved - which is what I want because the page "moves" every day if you get my meaning.
[*] I'm using a feature of a closed-source .NET CMS so my hands are tied.
Google's documentation seems to indicate that both 302 and 307 are treated equivalently, and that "Googlebot will continue to crawl and index the original location."
But in the face of ambiguity, you might as well dig into the RFCs and try to do the Right Thing, with the naïve hope that the crawlers will do the same. In this case, RFC 2616 § 10.3 contains nearly identical definitions for each response code, with one exception:
302: Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.
307: Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.
Which does not strike me as a significant distinction. My reading is that 302 instructs clients that webmasters are untrustworthy, and 307 explicitly tells webmasters that clients will not trust them, so they may freely alter the redirect.
I think the more telling point is the note in 302's definition:
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
Which, to me, indicates that 302 and 307 are largely equivalent, but that HTTP/1.0 clients failed to implement 302 correctly the first time around.
Short answer: neither. In most cases the code you really want to use is 303.
For the long answer, first we need some background.
When getting a redirect code the client can (A) load the new location using the same request type or (B) it can overwrite it and use GET.
The HTTP 1.0 spec did not have 303 and 307, it only had 302, which mandated the (A) behavior. But in practice it was discovered that (A) led to a problem with submitted forms.
Say you have a contact form, the visitor fills it and submits it and the client gets a 302 to a page saying "thanks, we'll get back to you". The form was sent using POST so the thanks page is also loaded using POST. Now suppose the visitor hits reload; the request is resent the same way it was obtained the first time, which is with a POST (and the same payload in the body). End result: the form gets submitted twice (and once more for every reload). Even if the client asks the user for confirmation before doing that, it's still annoying in most cases.
This problem became so prevalent that client producers decided to override the spec and issue GET requests for the redirected location. Basically, it was an oversight in the HTTP 1.0 spec. What clients needed most was a 303 (and behavior (B) above), but instead they only got 302 (and (A)).
If HTTP 1.0 would have offered both 302 and 303 there would have been no problem. But it didn't, so it resulted in a 302 which nobody used correctly. So HTTP 1.1 added 303 (badly needed) but also decided to add 307, which is technically identical to 302, but is a sort of "explicit 302"; it says "yeah, I know the issues surrounding 302, I know what I'm doing, give me behavior (A)".
Now, back to our question. You see now why in most cases you will want 303.
Cases where you want to preserve the request type are very rare. And if you do find yourself such a case, the answer is simple: use 302. Either the client speaks HTTP 1.0, in which case it can't understand 307; or it speaks HTTP 1.1, which means it has no reason to preserve the rebelious behavior of old clients ie. it implements 302 correctly, so use it!
5 years on... note that the behaviour of 307 has been updated by RFC-7231#6.4.7 in June 2014, and is now significantly different from a 302, in that the method may not change:
The 307 (Temporary Redirect) status code indicates that the target
resource resides temporarily under a different URI and the user agent
MUST NOT change the request method if it performs an automatic
redirection to that URI.
Probably not an issue for the original question, but may be relevant to others who come across this question just looking for the difference.
I feel your pain. As for a solution, it's hard to say what search engines will do. It seems that each one has its own way of handling redirects. This link suggests that a 302 will index the contents of the redirected page but still use the main page link, but it's not clear what a 307 will do.
Another way you could consider proceeding is with a javascript redirect and a <noscript> tag explaining what's going on. That will also foul up non-javascript browsers, and you'd have to proceed with caution to avoid Google's sneaky-site detection routine, but I suspect that as long as your noscript contains a hyperlink that matches the new URL you'd be OK.
Either way I'd still pursue doing a purely server-side request if at all possible. Heck, if your expected traffic is light, you could treat your home page as a proxy in the case where there's no querystring. Have it use a background thread to request itself with the querystring and pipe out the results. :-)
edit just saw you're using .NET. Maybe consider this answer from SO: C# Can i modify Request.Form's variables? .
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.