Redirecting to www

Question

Hi,
We have a code snippet that does a permanent redirect from domain.com to www.domain.com.  We place this code in onSessionStart and onRequestStart functions in Application.cfc  (let's just assume that there is a reason why we place it in both functions).
So the code has been working until last week when we moved from CF8 to CF9 (with Windows Server 2008).  Suddenly, instead of redirecting from http://domain.com/index.cfm to http://www.domain.com/index.cfm, the code redirects to http://www.domain.com/index.cfm,http://www.domain.com/index.cfm (yes, repeated with a comma).
After many testings, we finally figured out that this problem only occurs because we put the code in both onSessionStart and onRequestStart.  Somehow, both redirections get triggered though I don't quite understand how.  My understanding is that if a user types in domain.com in the beginning, onSessionStart will redirect him/her to www.domain.com.  The redirection code in onRequestStart should only get triggered if a user types in domain.com in the middle of his/her session.
Any idea why?  It worked fine in CF8 but not in CF9.
Thank you in advance!
<cffunction name="onSessionStart" returnType="void" output="true">
    <cfif cgi.server_name neq 'www.domain.com'>
        <cfheader statuscode="301" statustext="Moved permanently">
        <cfset strNewURL = "http://www.domain.com" & cgi.path_info>
        <cfheader name="Location" value="#strNewURL#">
    </cfif>    
</cffunction>
<cffunction name="onRequestStart" returnType="boolean" output="true"> 
    <cfargument name="thePage" type="string" required="true">
    <cfif cgi.SERVER_NAME neq 'www.domain.com'>
        <cfheader statuscode="301" statustext="Moved permanently">
        <cfset strNewURL = "http://www.domain.com" & cgi.path_info>
        <cfheader name="Location" value="#strNewURL#">
    </cfif>    
    <!--- This is to expire session so we can run the code again immediately (from rickosborne.org)--->
    <cfset ServerName=LCase(CGI.SERVER_NAME)>
    <cfset structClear(Session)>
    <cfloop condition="listLen(ServerName,'.') gte 2">
        <cfloop list="CFID,CFTOKEN,CFMAGIC,SESSIONID,JSESSIONID" index="CookieName">
            <cfcookie expires="NOW" name="#CookieName#" domain=".#ServerName#">
            <cfcookie expires="NOW" name="#CookieName#" domain="#ServerName#">
            <cfcookie expires="NOW" name="#CookieName#">
        </cfloop>
        <cfset ServerName=listRest(ServerName,".")>
    </cfloop>
    <cfreturn true>
</cffunction>

Answer 1

1.  The reason we put it at the beginning of onSessionStart is because onSessionStart has a number of instantiations (components and session variables).  So I thought if I just put the code only in onRequestStart, we would be 'wasting' those instantiations (ie. someone goes to domain.com, goes thorough all of onSessionStart function only to be thrown to www.domain.com with its own onSessionStart).
All the more reason to get this sorted out before CF gets involved, I'd say.  It takes about 30sec to sort this out on IIS.
  But I am curious to know why the code is not working as I expected.  Is it the way onSessionStart work or the way cfheader work?
I had a closer look at your code, and a bell started ringing.  I have some vague recollection that I found that when one uses <cfheader> to add the same header value multiple times, CF compiles it into one name/value pair, as a comma-delimited list.  I did raise this on some forum somewhere, but I cannot find it with Google.  You can probably test this by checking what's in the headers with an HTTP sniffer.
I suspect what's happening is that for a given request, all of onApplicationStart(), onSessionStart() and onRequestStart() (if applicable) will be processed, so you're actually adding the header twice, because both onSessionStart() and onRequestStart() are running.  You might be able to mitigate this by:
a) using <cflocation> instead of two <cfheader> lines.  I mean... why aren't you use using <cflocation> anyhow?
b) sticking a <cfabort> after the <cfheader> tags, in both cases.
But, really... use the web server to do a job that is actually intended for the web server to be doing.  This is a square peg / round hole situation you're trying to get working here.
Adam