A short post, although it took me a couple of hours to solve this one…

While working on a local development version of a web site project, I found that for some reason I was unable to log in to my CMS when testing with Internet Explorer. For the life of me I couldn’t work out what was going on — everything seemed to be working as it should, except that for some reason IE was regenerating its session cookie on every page load.

I tried everything I could think of, to no avail, until I stumbled this obscure response on StackOverflow. The reason in the end was very simple: IE doesn’t like underscore characters in domain names (although the answer incorrectly suggests that hyphens are problematic, too).

Fair enough, IE is adhering to the relevant RFC standard but to do so by silently ignoring cookies is just absurd. If it doesn’t support domain names with this character, surely it should just reject the whole site and give an error (e.g. “domain name contains illegal characters”)?

Sigh.

Today I received an email from a client that had just moved their site over to SSL (i.e. HTTPS) — they were no longer able to download files in Internet Explorer. When they tried to do so, a message would appear:

Unable to download...[file name]

The file could not be written to the cache

(an alternative error message is “Internet Explorer cannot download [file name] from [site].
Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.”)

I tried various suggestions: different response headers, settings to do with saving encrypted files, and even tried (and failed) to install a couple of hotfixes.

In the end, I’d nearly given up when I found this knowledgebase article and decided to have a go at manually adding the BypassSSLNoCacheCheck registry key.

Short story, it worked. It’s not great since it requires the user to do something — I couldn’t fix it server-side — but it was OK in this case because the site was an intranet so their IT people could sort it. Anyway, I hope this helps someone else out there…

UPDATE: OK, after a lot more experimentation I found a proper solution that doesn’t involve registry updates!

It’s a long story but it turns out that PHP was automatically sending an extra header (“Pragma: no-cache”) that I hadn’t noticed. So, I set the headers as follows:

header("Cache-Control: private");
header( "Pragma: private" );

…which overrides the automated headers and appears to solve the problem. Hurray!

In fact, it’s really quite easy, using .htaccess. Simply put, you use mod_rewrite to redirect all requests to the maintenance page, unless the user’s browser has a particular cookie.

RewriteEngine On
RewriteBase
RewriteCond %{HTTP_COOKIE} !^.*secret-cookie.*$ [NC]
RewriteRule .* maintenance-page.html [NC,L,R=503]

Clearly you can change the name of the cookie from ‘secret-cookie’ to whatever you like. Its value isn’t important. And of course, you can change the name of your maintenance page.

Update: as suggested by Michael, below, I’ve added the R=503 status code to indicate that the service is temporarily unavailable.

Now you just need to create the cookie in your browser. Personally I use the FireCookie extension for Firebug which makes this very easy.

That’s it!

I’ve tried several over the past 18 months or so, including FPDF and TCPDF. TCPDF is a direct wrapper for PDF functions, which means getting your head around PDF’s layout behaviour — powerful but rather time-consuming. TCPDF does the same but also provides the ability to import HTML documents — much easier, but unfortunately not as stable as one might hope: in particular I had problems with elements (e.g. tables) that spanned pages.

For my most recent project I’ve been experimenting with dompdf, which does away almost entirely with the notion of directly interacting with PDF layout in favour of attempting to provide more robust and flexible HTML import. As such it has impressively advanced CSS support, as well as excellent handling of tables and other markup. The documentation is somewhat lacking so in some cases it’s necessary to dig around in the support forum to find out what you need. But so far I’d say it’s by some margin the best of the libraries I’ve tried.

With some detective work they had discovered that somehow the ‘secure’ CMS part of the site — where the client can log in to make changes — was being crawled by automated search engines. Part of the CMS is a list of all the site’s pages, each with links to the usual operations — edit, delete etc.  When the spider was indexing the pages, it also accessed the delete link, thereby deleting the page (much like this DailyWTF story).

Oops.

Anyway I took a look and while the security wasn’t great — it was based around cookies with no server-side validation — it still seemed odd that the spiders were able to access the pages. I implemented a slightly more robust system using sessions, added an entry to robots.txt, and marked it as solved.

And then it happened again.

I couldn’t work out what was going wrong, so to stop it happening I converted all the delete links to forms. But it was nagging at me — how was it that the search engines were reaching the pages at all? Why weren’t they being rejected when the security script checked for a cookie and session?

Finally, the penny dropped…

The security check worked by looking for a valid session, checking it for a ‘user is logged in’ value, and if one wasn’t found then sending a redirect header pointing to the login page. Nothing unusual there. So what was going on?

When PHP sends a redirect header, the browser says “OK, I’ll go to this other page” and the user’s none the wiser. But just because the browser is no longer listening, that doesn’t mean the script automatically stops running. In fact, unless you tell it to stop it just continues as if nothing had happened. Thus, the spiders were simply ignoring the header and receiving the page as if there were no security in place at all.

The solution? Add an ‘exit;’ after the redirect header. Simple!

No more image replacement, or clunky sIFR nonsense to get pages looking as your clients actually want them to!

After that, I became aware that there’s more than one web site out there offering similar service. So here’s a run-down of those I know of — feel free to add a comment if you know of any that I’ve missed:

• WebFonts – as mentioned above, over 2,000 fonts to choose from and more on the way.
• Cufon – allows you to upload your own font files and then download them compiled for web use.
• FontFace – download pre-packaged ‘kits’ or roll your own.
• Google Web Fonts – yes, even the mighty Google is getting in on the act, although the choice is rather limited.

Update: From the comments (thanks!):

• Kernest
• FontsLive
• TypeKit
• TypeFront
• FontSpring
• FontDeck (closed beta as of this update)

Seems like it’s a technology whose time has arrived.

All was working smoothly using the ‘PayPal sandbox’ testing domain, but when it came to testing a live transaction in Internet Explorer I received the following error:

“Sorry, an Error Occurred After You Clicked the Last Link”

…followed by a lengthy but rather unhelpful block of text suggesting various courses of action — none of which was any use at all.

Consulting Google, it seems that this is far from an unusual occurrence but there’s little consensus as to the cause. In the end, I tried adding target=”_top” to the form that submits to PayPal (thus forcing the ‘pop-out’ of the iframe), and presto, all is now fine again.

I’m working on a navigation system that uses CSS image replacement. To hide the text, CSS shifts it out of view by using the text-indent property and a big negative value. However, a side-effect of this is that when you click on a link, the dotted border that appears while you’re holding the mouse button down goes off the side of the page.

To get around this, I just wanted to disable it. After some searching I discovered the outline property — setting this to ‘none’ gets rid of it entirely:

a{
outline: none;
}

Of course, the above will remove it for all links, it’s up to you to decide whether you want to make it more specific.

Briefly, the problem arises from the fact that the world is a sphere and representing it in two dimensions is not a straightforward task. There are various ‘projections’ to choose from, each of which uses a different method for mapping points — you can find out more in this Wikipedia article. The most common choice is the Mercator projection, where lines of latitude are spaced equally, and fortunately for me it’s the type of map used in the project I’m working on.

So, being somewhat mathematically inept, I decided that Google would save me from a day’s head-scratching. That turned out not to be the case, as I tried a good half-dozen different suggestions before finally stumbling across one that actually produced accurate results. To save others from the same fate I decided to reproduce here the code I ended up with, which is based heavily on code found in this newsgroup post. My implementation is PHP, but it shouldn’t be hard to convert it to another platform (see the original thread for a Javascript implementation). Apologies for the rubbish formatting, WordPress isn’t great at handling code:

function LongitudeToX( $lat, $lon, $map_zoom, $scale_value, $x_offset = 0 )
{
  $offset=16777216;
  $radius=$offset / pi();
  return ( ( ($offset+$radius*$lon*pi()/180)>>$map_zoom ) * $scale_value ) + $x_offset;
}
function LatitudeToY( $lat, $lon, $map_zoom, $scale_value, $y_offset = 0 )
{
  $offset=16777216;
  $radius=$offset / pi();
  return ( ( ($offset-$radius*log((1+sin($lat*pi()/180))/(1-sin($lat*pi()/180)))/2)>>$map_zoom ) * $scale_value ) + $y_offset;
}

A few notes about using these functions:

• From what I can tell, the above code is based on Google Maps and the $map_zoom relates in some way to the ‘zoom level’ of the map. I set it at 15 and it seemed to work OK.
• Because the dimensions of your own map might not exactly match the assumed dimensions of the map used in the calculation, the $scale_value parameter allows you to adjust the output to fit more precisely. I had to specify two decimal places of scaling to get an exact fit.
• Finally, the calculation assumes that the ‘origin point’ of the map (x=0, y=0) will be at the top, left-hand corner. This isn’t the case on the map I’m working on (the origin is at the centre) so I included $x_offset and $y_offset parameters so that I could adjust the output values accordingly.

In order to find the best values for the above parameters, I manually placed three widely-spaced temporary markers on the Flash map marking points whose latitude and longitude I already knew. Then I had the code render these points and adjusted the various parameters until the position of the generated points exactly matched the manually-placed markers.

I hope this code helps someone avoid wasting the sort of time I did yesterday!