I found this code for 301 redirects in ColdFusion:
<cfheader statuscode="301" statustext="Moved Permanently">
<cfheader name="Location" value="[the URL to be redirected to]">
<cfabort>
What file do I place this code in? Is it the "missing page" that is now supposed to be giving a 301 error when someone lands on it? Or is there a file that's similar to .htaccess that I should put it in?
First of all: 3xx status codes are not errors but redirects.
Your code snippet isn't wrong, but ColdFusion has a more comfy way to do these 3 lines with a single statement:
<cflocation url="[the URL to be redirected to]" statusCode="301">
You can put this tag anywhere in your .cfm template. ColdFusion executes everything up to this point and then stops execution, sets the response header accordingly, discards the output buffer (because 3xx are not supposed to contain a body) and transmits the response (header with location reference).
Note: Your code snippet would include content in the response body (e.g. everything you put in <cfoutput> tags), which is usually not desired. So I strongly recommend to use the cflocation tag for common redirects. It'll also protect you from forgetting to place <cfabort> after it.
For a common scenario like "redirect visitor from a no longer existing page to a new page", you can simply do this:
no_longer_existing_page.cfm
<cflocation url="the_new_page.cfm" statusCode="301" addToken="false">
the_new_page.cfm
<cfoutput>Hello World !!</cfoutput>
Requests to both pages will now point to the_new_page.cfm and return Hello World !!. (This is a redirect, not a rewrite, so the address in the browser will change to the_new_page.cfm in both cases.)
Related
I have an ASP.NET website. A user can access the URL /partners/{partner-id} in my app. When that url is invoked, I do two things:
1) I want to log the partner ID and user that requested it and
2) Redirect the url to the partner's website.
My question is, which HTTP Status Code should I use? I was using 301. However, that introduced a problem where my logging code was getting skipped. I suspect its because a 301 represents a permanent redirect. However, I basically want to remain the middle man so that I properly log the details.
What HTTP status code should I use?
Thanks!
Taking a look here:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
you should use the 302 status code. Two useful points about the 302 redirect:
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests
This says by inferring that the redirect may be temporary, clients should always check the initial URI instead of going to the redirect URI as a default behavior, meaning they will pass through your logging system each time rather than going directly to the redirected URI on subsequent requests. The 302 response also states:
This response is only cacheable if indicated by a Cache-Control or
Expires header field.
By default, the 301 redirect is cacheable unless you explicitly specify, but the 302 is not cacheable unless explicitly specified.
However, it's probably a good idea to explicitly add in 'do not cache' headers to the redirect to let the client know that it should not be cached just in case you have a client that doesn't follow the default spec behavior. There are a number of other answers in stackoverflow regarding this, here's a decent one:
How to control web page caching, across all browsers?
I am "renaming" an existing file for a project I am working on. To maintain backwards compatibility, I am leaving a cfm file in place to redirect the users to the new one.
buy.cfm: old
shop.cfm: new
In order to keep everything as clean as possible, I want to send the 301 statuscode response if a user tries to go to buy.cfm.
I know that I can use either cflocation with the statuscode attribute
<cflocation url="shop.cfm" statuscode="301" addtoken="false">
or I can use the cfheader tags.
<cfheader statuscode="301" statustext="Moved permanently">
<cfheader name="Location" value="http://www.mysite.com/shop.cfm">
Are there any reasons to use one method over the other?
I think they do the same thing, with <cflocation> being more readable
I tested this on ColdFusion 9.
There is one major difference, and it is that cflocation stops execution of the page and then redirects to the specified resource.
From the Adobe ColdFusion documentation:
Stops execution of the current page and opens a ColdFusion page or
HTML file.
So you would need to do this:
<cfheader statuscode="301" statustext="Moved permanently">
<cfheader name="Location" value="http://www.example.com/shop.cfm">
<cfabort>
to get the equivalent of this:
<cflocation url="shop.cfm" statuscode="301" addtoken="false">
Otherwise, you risk running into issues if other code runs after the cfheader tag. I came across this when fixing some code where redirects were inserted into an application.cfm file -- using cfheader -- without aborting the rest of the page processing.
I also noticed, in the response headers, that cflocation also sets the following headers accordingly:
Cache-Control: no-cache
Pragma: no-cache
One might want to add these headers in if using the cfheader tag with Location, if needed:
<cfheader name="Cache-Control" value="no-cache">
<cfheader name="Pragma" value="no-cache">
To elaborate on the Answer by Andy Tyrone, while they MAY do the same thing in certain circumstances, the CFHEADER method give you more control over the headers passed in the request. This becomes useful, for example, if you want to send cache control headers to a browser or content delivery network so that they do not keep hitting your server with the same old redirect request. There is no way (to my knowledge) to tell a CFLocation to cache the redirect.
I'm using the Google means of making my GWT app searchable (https://developers.google.com/webmasters/ajax-crawling/docs/getting-started), which works fine. Unfortunately, it seems Bing does not follow the same pattern/rule.
I thought I'd add a URL filter, based on user-agent to map all URL's of the form
http://www.example.com/#!blah=something
to
http://www.example.com/?_escaped_fragment_=blah=something
only for BingBot so that my CrawlerServet returned the same as the GoogleBot requests. I have a URLRewrite rule like:
<rule>
<condition name="user-agent">Firefox/8.0</condition>
<from use-query-string="true">^(.*)#!(.*)$</from>
<to type="redirect">?_escaped_fragment_=$2</to>
</rule>
(I'm using a user-agent of Firefox to test)
This never matches. If I change the rule to ^(.)!(.)$ and try and match on
http://www.example.com/!blah=something
it will work, but using the same rule
http://www.example.com/#!blah=something
will not work, because it seems the URL string the filter is using is truncated at the "#".
Can anyone tell me if it's possible to make this work.
The browser doesn't send the hash to the server, as you've discovered. Watching a given request, you'll see that it only sends along the url before the # symbol.
GET / HTTP/1.1
Host: example.com
...
From the link you mentioned:
Hash fragments are never (by specification) sent to the server as part of an HTTP request. In other words, the crawler needs some way to let your server know that it wants the content for the URL www.example.com/ajax.html#!key=value (as opposed to simply www.example.com/ajax.html).
From the descriptions in the text, it is the server's job to translate from the 'ugly' url to a pretty one (with a hash), and to send back a snapshot of what that page might look like if loaded with a hash on the client. That page may have other links using hashes to load other documents - the crawler will automatically translate those back to ugly urls, and request more data from the server.
So in short, this is not an change you should need to make, the GoogleBot will make it automatically, provided you have opted into using hash fragments. As for other bots, apparently Bing now supports this idea as well, but that appears to be outside the scope of your question.
It's well known that the URL fragment (the part after the #) is not sent to the server.
I do wonder though how fragments work when a server redirect (via HTTP status 302 and Location: header) is involved.
My question is really two-fold:
If the original URL had a fragment (/original.php#foo), and a redirect is made to /new.php, does the fragment part of the original URL simply get lost? Or does it sometimes get applied to the new URL? Will the new URL ever be /new.php#foo in this case?
Regardless of the original URL, if the server redirects to a new URL with a fragment (/new.php#foo), will the fragment get "honored"? Or does the server really have no business interfering with the fragment at all -- and will the browser therefore ignore it by simply going to /new.php??
Update 2022-09-22:
RFC 9110/STD 97 HTTP Semantics (which obsoletes 7231 (and others)), has been published as an INTERNET STANDARD in June 2022. The wording in the newly numbered Section 10.2.2 Location stays the same as before/below.
Update 2014-Jun-27:
RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, has been published as a PROPOSED STANDARD. From the Changelog:
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2)
The important points from Section 7.1.2. Location:
If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the URI
reference used to generate the request target (i.e., the redirection
inherits the original reference's fragment, if any).
For example, a
GET request generated for the URI reference
"http://www.example.org/~tim" might result in a 303 (See Other)
response containing the header field:
Location: /People.html#tim
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim"
Likewise, a GET request generated for the URI reference
"http://www.example.org/index.html#larry" might result in a 301 (Moved
Permanently) response containing the header field:
Location: http://www.example.net/index.html
which suggests that the user agent redirect to
"http://www.example.net/index.html#larry", preserving the original
fragment identifier.
This should clearly answer your questions.
Update END
this is an open (not specified) issue with the current HTTP specification. it is addressed in 2 issues of the IETF httpbis working group:
#6: Fragments allowed in Location
#43: Fragment combination / precedence during redirects
#6 allows fragments in the Location header. #43 says this:
I just tested this with various browsers.
Firefox and Safari use the fragment in the location header.
Opera uses the fragment from the source URI, when present, otherwise the fragment from the redirect location
IE (8) ignores the fragment in the location URI, thus will use the fragment from the source URI, when present
Proposal:
"Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence."
[...]
It appears that IE8 does use the fragment idenfitier from Location (the behavior I saw might be limited to localhost).
Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.
I therefore change my proposal to document that as expected behavior.
this leads to the most browser compatible and future proof (because this issue will eventually get standardized) answer to your question:
A: fragments from original URLs get discarded.
B: fragments from the Location header are honored.
Safari 5 and IE9 and below drop the original URI's fragment if a HTTP/3xx redirect occurs. If the Location header on the response specifies a fragment, it is used.
IE10+, Chrome 11+, Firefox 4+, and Opera will all "reattach" the original URI's fragment after following a 3xx redirection.
Test page: http://www.webdbg.com/test/redir/fragment/.
See further discussion of this issue at http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
Just to let you know, here you can find proper spec. by w3c defining how all should behave: http://www.w3.org/TR/cuap#uri - clause 4.1 - see below:
When a resource (URI1) has moved, an HTTP redirect can indicate its
new location (URI2).
If URI1 has a fragment identifier #frag, then the new target that the
user agent should be trying to reach would be URI2#frag. If URI2
already has a fragment identifier, then #frag must not be appended and
the new target is URI2.
Wrong: Most current user agents do implement HTTP redirects but do not
append the fragment identifier to the new URI, which generally
confuses the user because they end up with the wrong resource.
References:
HTTP redirects are described in section 10.3 of the HTTP/1.1
specification [RFC2616]. The required behavior is described in detail
in "Handling of fragment identifiers in redirected URLs" [RURL]. The
term "Persistent Uniform Resource Locator (PURL)" designates a URL (a
special case of a URI) that points to another one through an HTTP
redirect. For more information, refer to "Persistent Uniform Resource
Locators" [PURL]. Example:
Suppose that a user requests the resource at
http://www.w3.org/TR/WD-ruby/#changes and the server redirects the
user agent to http://www.w3.org/TR/ruby/. Before fetching that latter
URI, the browser should append the fragment identifier #changes to it:
http://www.w3.org/TR/ruby/#changes.
Posting similar issue with the solution faced by me.
Hope it helps to someone with the similar requirement of preserving hash in IE for 302 redirects.
Adding essential parts of the answer instead of links alone
We use SiteMinder authentication in our application.
I figured out that after successful authentication, SiteMinder is doing 302 redirection to user requested application page by using login form hidden variable value (where it stores user requested URL /myapp/ - without hash fragment since it won't be sent to the server) with name similar to redirect. Sample form below
Since redirect hidden variable value contains only /myapp/ without hash fragment and it's a 302 redirect, the hash fragment is automatically removed by IE even before coming to our application and whatever the solutions we are trying in our application code are not working out.
IE is redirecting to /myapp/ only and it is landing on default home page of our app https://ourapp.com/myapp/#/home.
Have wasted almost a day to figure out this behavior.
The solution is:
Have changed the login form hidden variable (redirect) value to hold the hash fragment by
appending window.location.hash along with existing value. Similar to below code
$(function () {
var $redirect = $('input[name="redirect"]');
$redirect.val($redirect.val() + window.location.hash);
});
After this change, the redirect hidden variable is storing user requested URL value as /myapp/#/pending/requests and SiteMinder is redirecting it to /myapp/#/pending/requests in IE.
The above solution is working fine in all the three browsers Chrome, Firefox and IE.
Thanks to #AlexFord for the detailed explanation and providing solution to this issue.
I'm using IIRF to redirect certain URLs to specific PDF files. For instance, for the URL /newsletter/2010/02 I'd like it to redirect to /pdf/newsletters/Feb2010.pdf. I'm not too hot at regular expressions, but I created the following rule:
RedirectRule ^/newsletter/2010/01 /pdf/newsletters/Newsletter012010.pdf [I,R=301]
and it does redirect, but the address bar doesn't change, and when trying to save the file it wants to save as 01 instead of Feb2010.pdf. I don't presume my users will be savvy enough to enter a PDF extension before saving, and they shouldn't have to. Is there anything I can do about this?
Two suggestions:
clear your browser cache
Redirect to a full URL. instead of /pdf/newsletters/Foo.pdf, redirect to http://server/pdf/foo.pdf
It's strange that it wants to use 01 as the file. Surprising. Are you sure the browser is sending a new request? Use Fiddler to verify. A redirect should result in the browser address bar getting updated, ALWAYS. If you get a 301 you will see it very clearly in the Fiddler trace.
If you don't see the expected 301, Is it possible that you previously used a RewriteRule in the ini file, and the browser cached the result, and now when you ask for /newsletter/2010/01 , you are getting the cached result, rather than the redirected URL from IIRF? Clear your browser cache and request it again, to test this.
I guess it would be easy to just clear the browser cache and re-try it, without even checking Fiddler.