Casey Lawler

me, rambling

‘Chrome Behaving Weirdly’

Tossing this into the random-stuff-I-learned-today bucket.

Today I was messing around with Google Chrome, and I found out that unlike Firefox and Safari, it treats frontslashes the same way as backslashes in hrefs.

A Chromium developer offers their thoughts on this:

…the backslash was intended to provide compatibility for a Windows world, and [Chrome will] take a more-or-less arbitrary number of initial slashes following the colon in some cases.

Try clicking the following links in Firefox, Safari, and Chrome to get a better sense of what this means:

<a href=“http://google.com”>

<a href=“http:\google.com”>

<a href=“http:\//\//\google.com”>

<a href=“//google.com”>

<a href=“\google.com”>

<a href=“\//\//\google.com”>

lolwut?

Now, this is admittedly super contextual, but this could mean the difference between a URI filter spitting out malformed garbage that doesn’t link properly and that same URI filter spitting out a valid link in Chrome. Construct your whitelists and filters with care!

I’ve hardly ever had reason to question Chrome’s behavior and my eyes glaze over re: Windows compatibility, but this is a great reminder that browsers do have their subtle differences which sometimes manifest in surprising ways.

Pretty unrelated: I also stumbled upon Garage4Hackers which I didn’t know is a thing. Might be worth checking out if you’re into security stuff.

‘Unpacking Gems’

This might be pretty obvious to more seasoned Rubyites, but I’m making a note of it here because this was news to me.

I often come across gems whose source code I want to read.

In a pinch, I’ll head to RubyGems, find the gem that I’m looking for, get linked to the repo, and view the gem’s source code through my web browser, typically with GitHub’s web viewer.

If I need to roll my sleeves up and I want to mess with the gem source, then I’d have to find a git clone link, switch back to my terminal, run git clone, check out the appropriate git tag for the version of the gem that I want to examine, etc. This can be a drag, and most of the time I’m not looking to contribute - I just want to read the source more comfortably.

You can unpack gems to your current working directory and browse their source code from the comfort of your text editor with this incantation:

1
gem unpack [gem_name]

Note that if you have multiple versions of a given gem installed at once, you can specify the version to unpack or have it default to the highest installed version number.

Visit this SO page for more details, but here are the important bits from the help output:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Usage: gem unpack GEMNAME [options]

  Options:
        --target=DIR                 target directory for unpacking
        --spec                       unpack the gem specification
    -v, --version VERSION            Specify version of gem to unpack


  Common Options:
    -h, --help                       Get help on this command
    -V, --[no-]verbose               Set the verbose level of output
    -q, --quiet                      Silence commands
        --config-file FILE           Use this config file instead of default
        --backtrace                  Show stack backtrace on errors
        --debug                      Turn on Ruby debugging


  Arguments:
    GEMNAME       name of gem to unpack

  Summary:
    Unpack an installed gem to the current directory