Direct, it seems, from the pit of “Code bugs only manifest themselves when you least expect them” horrors, comes this doozy.
If you have read a couple of recent blogs posts you’ll know that I’ve been slowly, step by step, making my various domains secure. (This one is the worst offender, but is also going to take the most effort because of *cough* GoDaddy *cough*, and its peculiar rules regarding SSL certificates.) One of the recent ones was my URL shortening domain
Until just recently.
A big principle with resolving bugs in code that has been working just fine for a long period of time is, What just changed? Answer that, and it helps you zero in on the reasons for the bug. Problem is, when I secured
jmbk.nl I did check that everything still worked. After all, it was my first ASP.NET site for which I’d done this, so obviously I’d have to make sure that the code still worked, that I’d updated the various bits and pieces that needed it. And, yes, it still served up short URLs.
Fine! Until about a week ago, when I wrote and published the previous blog post. Suddenly the service was not providing short URLs.
Time for some web developer tools. Firefox gave me just this error and no further hints:
Loading failed for the <script> with source “http://jmbk.nl/MakeUrl/?shorten=[FullURL]&callback=[ComplexGUID]”
To which all I could say was, holy crapola, my shortening service is no longer up. Except … it was. Googling the error didn’t bring up anything that I could use. I played around a bit with getting the error message returned from jQuery’s
getJSON() call, but that had the most helpful text I’ve seen yet: “
error”. I was pretty stumped. Even worse, checking my database of short URLs showed that the full URL for the new blog post had in fact been processed. The short URL had been generated. So the request was getting through, but the response (that is, the short URL) had not made it back.
Finally I tried it with Chrome. This gave me:
Refused to execute script from ‘http://jmbk.nl/MakeUrl/?shorten=[FullURL]&callback=[ComplexGUID]’ because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
(In my original post on the subject, I’d used
application/json instead. Because, you know, the important bit of the executable response is some JSON. Yeah, right.)
Admittedly, this fix doesn’t really address anything about why it suddenly wouldn’t work. It certainly wasn’t because I went secure (that bit did work with SSL active), but it must have been some tweak in Firefox in one of the latest versions that suddenly meant MIME types were being rigorously checked. Perhaps Chrome was reporting the error all along, but I wouldn’t know since I don’t use it regularly.