Category Archives: Uncategorized

In the early days of the web, HTML documents were served over HTTP. The original HTTP protocol was a simple human-readable ASCII implementation. Over time, two major changes came to HTTP: In 1994, Netscape introduced an encryption and verification layer known as HTTPS; and in 2015, the W3C finalized the HTTP/2 specification, which includes data compression and server push (bidirectional) capabilities.

HTTPS was originally envisioned only for high-security situations, like banking and e-commerce, but with en-route content injection and other security concerns, vendors began pushing for increased use of encryption and verification. In 2010, a Firefox extension “HTTPS Everywhere” was released, one of the first hints that all traffic would eventually be transferred over an encrypted channel.

Fast forward to 2016. Browser vendors have increased the urgency of moving sites to HTTPS. Google and Firefox have joined efforts to deprecate non-secure HTTP. W3C has joined in, saying that “We recommend that such legacy functionality begin requiring a privileged context as quickly as is reasonably possible.” Current versions of Chrome and Firefox already issue console warnings for data submission over HTTP, and within a year, in one of the first major breaks in backwards compatibility for the web, many existing capabilities will be rejected over HTTP.

Adoption of HTTPS has been held back by the cost of certification (a TLS certificate can easily more than double the cost of web hosting) and, for those running their own servers, the complexity of installation. To act as the carrot corresponding to the aforementioned stick, major web players have created the Extended Verification certificates.

Domain operators who have not yet done so should move to HTTPS by:

1. Acquiring and installing a TLS certificate from Let’s Encrypt or another reputable source.
2. Verify and correct any failing/warning components (in particular, any absolute URLs involving http:// should be identified and replaced with https://, as these will cease to work in the future)
3. Adding a server rewrite rule to redirect all HTTP requests to HTTPs.
4. Ensuring that subsequent client connections can’t be hijacked via HTTP using HSTS to tell the client to never attempt to connect over non-secure HTTP again. An additional server rewrite rule enables HSTS.

You can check the certificate of your site by verifying the green lock icon:

You can also check that HSTS is forcing the HTTPS version of your site by attempting to go to the HTTP only URL and observing an “internal redirect”:

We’re all familiar with the try-catch idiom for handling exceptions. And of course, every primer on try-catch also introduces the finally block. It’s often unclear, however, when finally should be used. In other words, if I have a try-catch like so:

try {
  // do action
} catch {
 // handle error
} finally {
 // clean up
}

Why can’t I just

try {
  // do action
} catch {
 // handle error
}

// clean up

If this were an interview, we might answer mechanically: the finally will run even if the catch doesn’t catch the specific exception (if the catch is narrow), or if the catch rethrows the exception, or an exception occurs in the catch block. Putting the cleanup outside the finally will not be run in those cases.

But those cases are not too common, and then the finally is forgotten.

Consider the following case of a maintenance routine that requires a listening host be temporarily suspended. The maintenance routine may throw an exception, however, a higher-level exception handler (catch) already exists which implements the desired logging response:

StopHost();

DoMaintenance();

StartHost();

The problem, of course, is that when DoMaintenance throws an exception, it will bubble up to the catch handler and StartHost will never happen. This was an actual bug I encountered. The exception handler worked correctly, logging the fault, but the host was never restarted resulting in a system down until the next maintenance window.

I don’t really want to handle the exception at this level, but I do want to make sure that the host gets started again regardless of the outcome of the maintenance. Solution? finally!

StopHost();

try {
  DoMaintenance();
} finally {
  StartHost();
}

You don’t need a catch block to take advantage of finally.

MSDN Article on try-finally

In the past, web developers bemoaned having to implement workarounds and hacks to deal with older versions of Internet Explorer.

Lately we’ve experienced a spate of problems with Safari on iOS devices. A quick search turns up that Safari on iOS 7 is the buggiest Safari version since 1.0. Although I didn’t discover the particular issue and solution discussed here, this is something our team has been struggling with for a few days and the solution is strange.

A mobile web application, which works fine on Chrome on Android, was having strange rendering issues on Safari on iOS devices. In particular, the page would arbitrarily partial render and stop. However, “bumping” (scrolling the status bar, or any other small scroll attempt) would complete the rendering. The rendering would freeze in different places and at different times, but bumping would always resolve the issue.

A lot of searches turned up fruitless and the issue was very frustrating. The main developer on the project discovered there was an issue with refresh on iOS 7 related to the size of the page. We tried hacks like those described on the lazy repaint page, to no avail.

Finally, the developer determined that while the page was loading, the changing of DOM elements was causing the page to attempt to scroll, which disrupted the rendering of DOM elements. Apparently, the “bumping” interrupted that process and allowed the render to complete (not exactly sure how that worked though).

For some reason, setting the viewport of the page resolved the issue. Note that setting only the width causes the app to work fine in landscape mode but not portrait mode.

<meta name="viewport" content="width=device-width, height=device-height">

I’m sure there’s a better explanation, but for now, we’re writing this as a weird Safari iOS 7 mystery bug.