Parameter Passing and Redirect Craziness: 301 redirects, Fragment Identifiers (Hash – #), Query String Variables

Parameter Passing and Redirect Craziness: 301 redirects, Fragment Identifiers (Hash – #), Query String Variables
Rate This Post

Some key points/themes:

  • in 301 redirects, parameters often do not get passed on as either the server config (server-side script, .htaccess, mod_rewrite or server/CMS config) is not set up to do so. Ensure to consult relevant parties (e.g. IT, web devs etc) when unsure. See below for tips.
  • the fragment (hash – #) are not passed to the server from your browser so you cannot depend on them in all scenarios. Hashes are maintained on the client-side only.
  • browser behavior differs when it comes to propagating/passing on fragments with 301 redirects. Fragment passing seems specific to browser implementation (e.g. Safari, IE, Chrome, Firefox, Opera, and Webkit-based browsers)

What is all this nonsense and why should I care?

Sometimes we need to pass parameters (query string) into our page to activate functional behavior or to track content (Google Analytics [GA], for example), or in some cases link users to right/specific portions in the content (hash).

Many groups (e.g. marketers, webmasters, analysts etc.) should be aware of the implications and details of redirects, parameter structure and fragments as their campaigns, measurement and implementation of their sites depend on these aspects. Think vanity urls (e.g. shortners), analytics packages etc.

In some cases, if parameters are not set/passed on, we cannot track campaigns properly. For example, if we use a vanity url and we want to use GA campaign tracking (UTM) parameters, we need to be certain the querystring variables are passed to our page with the GA snippet properly.

To get some terminology straight:

http://mysite.com?p=internet&r=email#mysection

In the above URI it has:

  •  (query string) parameters: parameter “p” is set to internet and parameter “r” is set to “email”
  • A fragment (fragment identifier): the fragment is set to “mysection”. This refers to a section on the page. A user typically jumps to that portion of the page if they access the URI.

Redirect Shenanigans – Passing Paremeters along – samples

When redirects come into the picture, parameters often do not get passed on as either the server config (server-side script, .htacess, mod_rewrite or server/CMS config) is not set up to do so. The following example is a way (server-side script) you can ensure to pass query string parameters along (PHP)

PHP Code   
  1. <?php
  2.     header("Location: http://yoururl.com/campaign.html?". $_SERVER['QUERY_STRING'], true, 301);
  3.     exit;

For Apache users who want to use rewrite rules, the query string parameters are passed along if you use the QSA flag in the rewrite rule.

  1. <IfModule mod_rewrite.c>
  2.     RewriteEngine On
  3.     RewriteRule ^(.*) http://mysite.com/ [R=301,NC,QSA]
  4. </IfModule>

Fragments and Redirects/Vanity URLs

After testing some 301 redirects and fragments, it seems that different browsers seem to handle it differently. So for example, if you had a vanity URI of http://mysite.com#afrag some browsers tack on the “afrag” fragment after the URI finishes the 301 redirect. Though this is not an exhaustive list, I noticed:

  • Passes the fragment: Chrome (Windows and Mobile), Chrome Canary 36, Firefox, IE 10+, Opera 12, Webkit-ish browsers (e.g. Android default Browser)
  • Removes the fragment: Safari 4/5 (Windows), IE 7/8

The lesson is that we cannot assume that all users will get the fragment passed along in a 301 redirect. It’s just a nuance to be aware of from a consistency and user experience standpoint.

References: http://www.w3.org/DesignIssues/Fragment.html