Category Archives: Web Design

Solved: NginX serving different localhost sites to Chromium vs. Safari or Firefox

I ran into a weird problem testing some websites on a local NginX installation on my Mac, where it was sending different sites to Firefox and Chrome for the same URL.

I’d put the server names into /etc/hosts pointing to 127.0.0.1, and I’d set up NginX with multiple server {} blocks, each with a different server_name. But while Chrome would load the individual sites for one.example.com and two.example.com, Firefox would always get the content from one.example.com.

A little more testing confirmed that all Chromium-based web browsers (I tried Edge, Opera, Brave and Vivaldi) were getting the correct sites, but Firefox and Safari were both getting the wrong server’s content.

When I compared the server blocks, I noticed that one.example.com was listening on both IPv4 and IPv6, but two.example.com was listening only on IPv4. I added the second listen directive, reloaded nginx, and voila! It worked in Firefox and Safari!

    listen 443 ssl;
    listen [::]:443 ssl;
    server_name  two.example.com;

So apparently, even though I’d only pointed two.example.com to 127.0.0.7 (IPv4), Firefox and Safari were connecting to ::1 (IPv6) instead. And since NginX had only connected one.example.com to that interface, that’s the site it loaded. It’s not clear whether Firefox and Safari are both doing something weird and Chrome isn’t, or they’re both using a MacOS system resolver and Chromium is doing its own thing.

TL;DR: If you listen to IPV6 in one localhost server {} block, listen to it in all of them!

Trying to get at the features left out of the mobile app

I use extensive filters on Gmail to categorize mail the way I want. I pre-filter some things to look at later, prioritize some lists (like allergy or uptime alerts), and pre-categorize things that I may want to file away after looking at them.

The problem is, I can only change filters on the desktop site. When I’m reading on my phone, I need to remind myself not to archive or delete messages that I want to start filtering.

It occurred to me: I can label those messages “Change Filter.” I could even do it right away – there’s a “Manage labels” option on the Android app!

Nope!

I can’t add labels in the app, just change the download and notification settings for each.

So, website then…

Except I can’t get at the full Gmail website on my phone. Or my tablet. Google insists on showing a stripped-down mobile site, which has even fewer capabilities than the app.

I can’t fault them for starting with the mobile site. It is helpful to focus on the features that work best on small touchscreens, under-powered processors, and high-latency, low-bandwidth networks, and can be done by someone on the go, rather than someone sitting at a keyboard with a big screen and a mouse.

But if someone wants to use the functionality you’ve left out, and is willing to slog through the desktop site on their phone or tablet, you should at least let them get at it!

In this case I waited until I could log in on a desktop, then added the label. But not everyone with a phone has a desktop or a laptop. And as the balance keeps shifting towards phones as people’s primary internet access device, that’s going to be more and more common.

Broadcasting “Likes”

I figured out exactly what bugs me about Twitter and Facebook showing your friends’ “likes” in the timeline. It’s not just that they’re public — that’s true on Tumblr or Flickr or Instagram too, but you only see them when you choose to look for them.

It’s that broadcasting likes in the newsfeed blurs your intent.

  • A “like” is a message to the original post’s author (and a bookmark for yourself).
  • A retweet or share is a message to your friends or followers.

Putting them in your followers’ feeds turns a “like” into a message to them as well, even though it’s not what you intended. (If you wanted to share it, you would have shared it, right?) It’s a step above completely frictionless sharing, but it still messes with the signal/noise ratio of the timeline.

Why I Hate Infinite Scroll

Infinite scroll is like finishing a sandwich, and the server plops another one in front of you without asking what you want on it, or if you want it at all. If you’re full, or you don’t like what they chose? Too bad, it’s on your plate now! To make matters worse, sometimes if you put the sandwich down for a moment to eat some chips, they’ll think you’re done and swap your sandwich for a different one!

Slate just replaced pagination with infinite scroll on their articles. Yes, pagination sucks. A multi-page article on the web is like a burger that’s been sliced up into wedges, and you only get one wedge at a time, forcing you to go back to the counter every few bites. But infinite scroll isn’t an improvement.

Both approaches impose the wrong structure on a single unit. Search results and timelines are one thing, but for an individual piece of content, the best way to map it to a web page…is to just map it to a web page.

Update (Sep 2016): Combined with giant images and complex layouts that slow down browser rendering (*cough* CBR), it’s even worse. To continue the lunch analogy:

  1. You order a sandwich with a cup of soup and a side salad.
  2. After an interminable wait, you get the sandwich and soup, but no salad, and no spoon. The waiter rushes off before you can say anything.
  3. Eventually you’re able to flag someone down and ask for the spoon and the salad.
  4. You munch on the sandwich by itself, which is at least a decent sandwich.
  5. Finally the waiter comes back with a whole pizza, and takes away your half-eaten sandwich.
  6. You still don’t have a spoon, but that doesn’t matter because the waiter took the soup too.

Feedly 404 Feedback Loop

I set up 404 Notifier when I moved my Les Mis commentary to its own blog, to catch anything I might have missed while getting content moved and the new site set up. I then added the RSS feed to Feedly.

After a few weeks, I started noticing some odd links showing up to /r/bienvenu, but I couldn’t find anything that linked to that URL. Then I looked closer and realized it was Feedly itself that was hitting the link!

Basically:

  1. Broken URL gets hit.
  2. 404 Notifier adds the hit to the feed.
  3. Feedly retrieves the feed.
  4. Feedly follows the URL!
  5. Return to step 1.

The timing is inconsistent, but I think Feedly might be hitting the URL whenever I look at the list of “articles,” maybe checking for an image to use for the card in magazine view. And based on the first instance in the DB, I think it may have been a URL I used to test the plugin when I first installed it, then forgot.

For now, I’ve just removed the feed from Feedly. I’m considering altering the plugin to skip hits from Feedly, but I can probably just turn it off now that the blog has been up for a month. It’s served its purpose. If anything, it might make more sense to put it on this site to see if I missed any redirects (though I haven’t actually removed the old copies of the posts yet).