function parseLocation() {
	var turl = window.location.search;
	ar = turl.split('&');
	var b = {};

	for (var i = 0; i < ar.length; i++) {
		var c = ar[i].split('=');
		b[c[0]] = c[1];
	}
	return b;
}

and you’ve thought, “oh, look how nice and compact that is. I shall use it post-haste!” Well, let me, as Mr. Guy Who’s Gotten Plenty Of Grumpy Complaints About This, light a candle rather than curse your darkness.

It is a good method, don’t get me wrong. It works great in theory. The problem is, say you copy/paste you url into, say, your Blogging Software of choice*. It might then re-interpret your url from:

http://post-hipster.com/parsey.html?var1=hey&var2=mambo&var3=fagabefe

into

http://post-hipster.com/parsey.html?var1=hey&var2=mambo&var3=fagabefe

and, on some browsers*, no amount of encode() or decode() will make that go away, which, in essence, changes your parsed variable names int “amp;var2″ and “amp;var3″

My solution, however inelegant, is to make the function explicitly look for the variables in question:

function parseLocation() {
	var turl = window.location.search;
	ar = turl.split('&');
	var b = {var1:'default_for_var1', var2:''};

	for (var i = 0; i < ar.length; i++) {
		var c = ar[i].split('=');
		if (c[0].indexOf('var1') > -1) {
			b['var1'] = c[1];
		} else if (c[0].indexOf('var2') > -1) {
			b['var2'] = c[1];
		} else if (c[0].indexOf('var3') > -1) {
			b['var3'] = c[1];
		}
	}
	return b;
}

I know, I coulda just RegEx’ed the ‘amp;’ away, but this way prevents any other encoding mishaps. If this was a global function, across a buncha different pages, I probably would just look for and get rid of the ‘amp;’

So there you go. Unfortunately, URL parsing isn’t always as nice as we want it  to be.

* unfortunately I can’t be more specific than this, because I haven’t yet been able to duplicate the error on any browser / os combination I’ve tried, but I’ve gotten enough complaints about it to know that it exists.

Share/Save

Well, it turns out they’re both wrong. With the latter, the problem is, a browser has an internal page-level memory space that it will “remember” image urls with. When you create an image in javascript (via an Image() object or innerHTML, take your pick), if that image src has already been requested once on that page, the browser will give you that image from its internal memory, regardless of the image’s Expire or Cache-control headers. It won’t be put into the browser’s cache, sure, but it still stays in the browser’s memory for as long as you’re viewing that page.

The former seems to be the quick fix – the image src is always unique, so it’s not in memory, and the browser will ping the server for the image. But this approach fails if you’ve actually set your target image’s headers correctly (which of course you should). Because with this approach, the server sees each request as unique, and will send a new copy of the image down the pipe, regardless of if you wanted it to or not. You’re similarly screwed if you’re working on a  high-traffic sites using a CDN – since a CDN (usually) contains cached copies of files from a master server, adding the cache-busting parameter to an image on a CDN will force the CDN to re-acquire the image from the master server before sending the image, which defeats the whole purpose of using a CDN in the first place.

The solution, unfortunately, is pretty hacky – to add a hash mark (#) to your image before applying a cache-busting parameter, i.e.:

function updateImage() {
	document.getElementById('image_arena').innerHTML = '<img src="/your/constantly/updating/image.jpg#e' + Math.random() + '">';
	setTimeout(updateImage, 60000);
	return;
}

This will psyche out the browser into thinking the URL of the image is unique (“Hey Firefox, look over there! PSYCHE!!11!”), but in the actual HTTP request anything beyond the hash gets stripped before the request is made. So, the browser thinks the request is unique and pings the server for it, but the server will know for reals wether or not the request is new, and send the appropriate 200/304 response*. Everyone’s happy, except for possibly your sense of aesthetics, since that is an ugly url you’re passing. But since you’re the only one who will probably see them, you’ll be alone in your secret shame.

*Yes, I did just bust some HTTP response codes.

Share/Save

Share/Save

Now let’s say you want to access a page on this site from an <iframe> from an external domain, say www.whowantsathroatpunch.com. Stupid IE6 will not send the right cookies in the request headers. In fact, I’m pretty sure it will send no cookies. Why? Because it’s a dick. Every Other Browser does this correctly. It’s not a security issue -it’s not like you’re asking IE6 to send cookies that belong to another domain, or to teach our nation’s children to read or anything. You’re asking the browser for the cookies that have been previously set, and IE6 in its infinite dick-kickery is failing in that basic respect.

What really gets my goat is that, whereas the iframe will not get its cookies, if you make the src of the iframe do an AJAX request to another page on the site, that request will get its cookies sent correctly.

The workaround I found is to give the <iframe> src a new page if the browser is IE6, and on that new page, make an AJAX request to another new page that outputs the value of the cookie you’re looking for. When you receive the AJAX request, you can then parse the response and redircet the user to the now-corrected original <iframe> src. It’s stupid and inefficient, I know:

<script type="text/javascript">
	// note: this page only called from IE6, so no browser testing
	// or compatibility checks are needed. I'm rocking the prototype.js for
	// the ajax, you do what you like.

	function editionTest() {
		var test_url = '/cookie_tester.php';
		var domain = new Ajax.Request(test_url, {
		    method:'get',
    		onSuccess: function(transport){
				var response = transport.responseText;
				if (response.search('site_a') > -1) {
					redirector('a');
				} else if (response.search('site_b') > -1) {
					redirector('b');
				} else {
					redirector('');
				}
    		},
			onFailure: function() {
				redirector('');
			}
		  });
	}

	function redirector(domain) {
		var url = parseUrl();
		var id = url['id'];
		var var = url['var'];
		var domain_parsed = 'http://' + domain + '.throat-punch.com/page_you_really_wanted.php?id=' + id + '&var1=' + var1;
		window.location = domain_parsed;
	}

	function parseUrl() {
		var hash = {};
		var url = String(document.location).split('?');
		if (url[1]) {
			var vars= url[1].split('&');
			var ct = vars.length;
			for (var i=0; i<ct; i++) {
				var item = vars[i].split('=');
				var name = item[0];
				var value = item[1];
				hash[name] = value;
			}
		}
		return hash;
	}

Event.observe(window, 'load', function() {
	editionTest();
});
</script>

I’m writing this post solely for google to pick it up, just in case anyone ever is in this position again. So, dude who googled “ie6 cookies iframe 302 throat punch”, this one’s for you.

(thanks to celebdu for the photo)

Share/Save

Share/Save

…so I wrote (what I think is a) clever little function (well, two functions) to take a complex php variable and turn it into a json-ized string, ready to be passed back to javascript. It works on the principle that json really only has a couple rules if text formatting: strings go inside double quotes, with both slashes and double-quotes escaped, iterative arrays are comma delimited inside brackets [obj1,obj2], and associative arrays go inside curly-brackets {key:val,key:val}. Using these three points, and a little bit (ok, a lot of) recursion, and voila, an elegant little function.

Of course, this doesn’t handle unicode, or any really special cases, but if you’re looking for a basic object parser, and you dont’ have access to php 5.2, which has it built into the language, it’ll do the trick…

/**
 * input an object, returns a json-ized string of said object
 * @return
 * @param $obj Object
 */
function php_json_encode($obj) {
	if (is_array($obj)) {
		if (array_is_associative($obj)) {
			$arr_out = array();
			foreach ($obj as $key=>$val) {
				$arr_out[] = '"' . $key . '":' . php_json_encode($val);
			}
			return '{' . implode(',', $arr_out) . '}';
		} else {
			$arr_out = array();
			$ct = count($obj);
			for ($j = 0; $j < $ct; $j++) {
				$arr_out[] = php_json_encode($obj[$j]);
			}
			return '[' . implode(',', $arr_out) . ']';
		}
	} else {
		if (is_int($obj)) {
			return $obj;
		} else {
			$str_out = stripslashes(trim($obj));
			$str_out = str_replace(array('"', '', '/'), array('\"', '\', '/'), $str_out);
			return '"' . $str_out . '"';
		}

	}
}

function array_is_associative($array) {
	$count = count($array);
	for ($i = 0; $i < $count; $i++) {
		if (!array_key_exists($i, $array)) {
			return true;
		}
	}
	return false;
}

Share/Save

But you know what? It bugs the snot out of the rest of us. It’s unnecessary, it’s indulgent, and… personally it bugs me so much that even if your intro ended with a retinue of topless Hawaiian maidens who would actually pop out of the screen and gently fan me with palm fronds while I viewed your website, I’d still skip it.

Instead of a “skip intro” button, how about a “show intro” button? That way, you still get to flex your Object Tweening skillz, your client can still show off your snappy work to all his buddies, and, most importantly, your audience’s first impression with your website is not an aggravated search for the “Skip” function.

And, for god’s sake, enough with the music backgrounds. If you must have one, have it in your “intro” only. If I wanted to listen to bland electronacia I’d bring my laptop to a Banana republic.

I’m looking at you, that one development team that seems to have built the website for every restaurant in Atlanta….

Share/Save