Web developer, open source enthusiast, amateur photographer & Linux user. Blogs @ http://t.co/Xgj1dYR9wb (en) & http://t.co/m0VDEYHnHq (fi)
34 stories
·
1 follower

HTTP/2 Server Push

2 Shares

Introduction

HTTP/2 is designed to address many of the failings of HTTP/1.x. Modern web pages use many resources: HTML, stylesheets, scripts, images, and so on. In HTTP/1.x, each of these resources must be requested explicitly. This can be a slow process. The browser starts by fetching the HTML, then learns of more resources incrementally as it parses and evaluates the page. Since the server must wait for the browser to make each request, the network is often idle and underutilized.

To improve latency, HTTP/2 introduced server push, which allows the server to push resources to the browser before they are explicitly requested. A server often knows many of the additional resources a page will need and can start pushing those resources as it responds to the initial request. This allows the server to fully utilize an otherwise idle network and improve page load times.

At the protocol level, HTTP/2 server push is driven by PUSH_PROMISE frames. A PUSH_PROMISE describes a request that the server predicts the browser will make in the near future. As soon as the browser receives a PUSH_PROMISE, it knows that the server will deliver the resource. If the browser later discovers that it needs this resource, it will wait for the push to complete rather than sending a new request. This reduces the time the browser spends waiting on the network.

Server Push in net/http

Go 1.8 introduced support for pushing responses from an http.Server. This feature is available if the running server is an HTTP/2 server and the incoming connection uses HTTP/2. In any HTTP handler, you can assert if the http.ResponseWriter supports server push by checking if it implements the new http.Pusher interface.

For example, if the server knows that app.js will be required to render the page, the handler can initiate a push if http.Pusher is available:

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        if pusher, ok := w.(http.Pusher); ok {
            // Push is supported.
            if err := pusher.Push("/app.js", nil); err != nil {
                log.Printf("Failed to push: %v", err)
            }
        }
        // ...
    })

The Push call creates a synthetic request for /app.js, synthesizes that request into a PUSH_PROMISE frame, then forwards the synthetic request to the server's request handler, which will generate the pushed response. The second argument to Push specifies additional headers to include in the PUSH_PROMISE. For example, if the response to /app.js varies on Accept-Encoding, then the PUSH_PROMISE should include an Accept-Encoding value:

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        if pusher, ok := w.(http.Pusher); ok {
            // Push is supported.
            options := &http.PushOptions{
                Header: http.Header{
                    "Accept-Encoding": r.Header["Accept-Encoding"],
                },
            }
            if err := pusher.Push("/app.js", options); err != nil {
                log.Printf("Failed to push: %v", err)
            }
        }
        // ...
    })

A fully working example is available at:

$ go get golang.org/x/blog/content/h2push/server

If you run the server and load https://localhost:8080, your browser's developer tools should show that app.js and style.css were pushed by the server.

Start Your Pushes Before You Respond

It's a good idea to call the Push method before sending any bytes of the response. Otherwise it is possible to accidentally generate duplicate responses. For example, suppose you write part of an HTML response:

<html>
<head>
    <link rel="stylesheet" href="a.css">...

Then you call Push("a.css", nil). The browser may parse this fragment of HTML before it receives your PUSH_PROMISE, in which case the browser will send a request for a.css in addition to receiving your PUSH_PROMISE. Now the server will generate two responses for a.css. Calling Push before writing the response avoids this possibility entirely.

When To Use Server Push

Consider using server push any time your network link is idle. Just finished sending the HTML for your web app? Don't waste time waiting, start pushing the resources your client will need. Are you inlining resources into your HTML file to reduce latency? Instead of inlining, try pushing. Redirects are another good time to use push because there is almost always a wasted round trip while the client follows the redirect. There are many possible scenarios for using push -- we are only getting started.

We would be remiss if we did not mention a few caveats. First, you can only push resources your server is authoritative for -- this means you cannot push resources that are hosted on third-party servers or CDNs. Second, don't push resources unless you are confident they are actually needed by the client, otherwise your push wastes bandwidth. A corollary is to avoid pushing resources when it's likely that the client already has those resources cached. Third, the naive approach of pushing all resources on your page often makes performance worse. When in doubt, measure.

The following links make for good supplemental reading:

Conclusion

With Go 1.8, the standard library provides out-of-the-box support for HTTP/2 Server Push, giving you more flexibility to optimize your web applications.

Go to our HTTP/2 Server Push demo page to see it in action.

Read the whole story
iiska
21 days ago
reply
Oulu, Finland
Share this story
Delete

Screenshot? Ugh, you’re doing it wrong!

1 Share

A proper sharing feature has been part of iOS for years. It has a consistent, system-level UI that’s available from most any app with anything worth sharing and yet no one seems to use it. Well, no one but us geeks, right? Everyone else just takes screenshots—which require mastering an unintuitive multi-button press and a fair amount of dexterity.

I moaned when people started posting screenshots of highlighted selections from articles to beat the 140 character limit on Twitter because they just shared a picture of text that I can’t copy, reformat, enlarge, etc. I’ve been that guy when friends send a screenshot of a product rather than a link. Sharing properly is a very type-A process that I dutifully complete out of ease for my friends and respect for the content!

That’s why my inner pedant was delighted when Instagram noticed I had taken a screenshot and gently nudged me to use the proper share features.

Use the hardware buttons to make a screenshot and Instagram is all, “Oh silly luddite, please send people a functional link.” Tapping the Share banner in the second screenshot corrects your bad form and helps you share a URL.

It’s a really nice solution that gently guides the user to the correct way to share. I’ll admit this is probably the solution I’d have designed, too. The built-in Share feature should be easier and yet friends and relatives who can barely download an app find screenshotting to be second nature.

That’s why I was delighted to see Amazon’s take on the same problem. Where Instagram’s design is a gentle scolding, Ahem! I see you have no idea what you’re doing, Amazon’s much scrappier version says, Oh you made a screenshot? Cool, lemme help you with that.

“I got you, bro.”

Amazon shows a similar, though more obvious, banner after you make a screenshot but it does things a little differently after that. For one, it uses the system’s Share Sheet which is familiar and provides a lot more options than Instagram’s custom one.

More important than that, however, is the payload. Amazon shares my screenshot and then adds a URL to it. It’s a subtle difference but Amazon’s version makes me feel better. Where Instagram gets my intent and tries to help me do the right thing, it replaced my content. Amazon’s design let’s me do what I intended but helps me do it better. In the screenshots above a major difference is posting to Twitter. Instagram’s post wouldn’t include an image, Amazon’s would.

As a designer I love being surprised by solutions I wouldn’t have come up with. I can absolutely see how Instagram arrived at their solution. Part of UI design is guiding users back when they go off track. Designers want to change the world by making things easier, more understandable, more enjoyable—more ideal. That completely resonates but I can’t help but admire the audacity of Amazon’s designers who have accepted the world as it is and humbly offered a helping hand. Kudos!


Screenshot? Ugh, you’re doing it wrong! was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read the whole story
iiska
39 days ago
reply
Oulu, Finland
Share this story
Delete

Vomiting Emoji

5 Comments and 12 Shares
My favorite might be U+1F609 U+1F93F WINKING FACE VOMITING.
Read the whole story
iiska
41 days ago
reply
Oulu, Finland
Share this story
Delete
5 public comments
aneweducation
37 days ago
reply
Yeah these emojis are too lit for me lol
Cleveland, OH
JayM
40 days ago
reply
Is there a generic emoji representing emojis? That one vomiting on itself sounds good to me.

Get off my my lawn.

I have had this lawn, TCP/IP across non-private only links/systems aka Internet, since 1989 or so... UUCP and nn since 1985.
Atlanta, GA
dbt
40 days ago
reply
Vomiting statue of liberty, now there's a perfect use of emoji right now
Palo Alto, CA
alt_text_bot
41 days ago
reply
My favorite might be U+1F609 U+1F93F WINKING FACE VOMITING.
drchuck
41 days ago
reply
😧
Long Island, NY

MIDI DrawingsCollection of musical scores by Mari Lesteberg...

2 Shares






MIDI Drawings

Collection of musical scores by Mari Lesteberg which present visual narratives with the music they dictate:

Inspired by Andrew Huang and his MIDI unicorn, I make midi compositions that forms a picture. It’s called a MIDI drawing, and it’s entirely stupid, but incredibly fun to make. 

More Here

Read the whole story
iiska
43 days ago
reply
Oulu, Finland
miohtama
46 days ago
reply
Helsinki, Finland
Share this story
Delete

Integrating scripts in Nautilus to perform useful tasks

1 Share

Files (also known as Nautilus) is the default file browser in Fedora Workstation. One of the super-handy, yet lesser known features in Nautilus is the ability to add scripts to run against one or more files. You can use this feature to script simple tasks like converting files from one format to another.

In this tutorial, we will cover how to set up Nautilus to add scripts, and create a simple bash script to convert images to JPEG format using the ImageMagick convert command. This will allow you to select one or more image files in Nautilus, and execute the script to convert them all to the JPEG format.

1. Create the scripts directory

The first step into adding scripts to Files is to create the directory where it expects your scripts to be. If it doesn’t exist already, create the following directory:

mkdir -p ~/.local/share/nautilus/scripts/

2. Create the script

Next, using your favourite text editor, create your script in the scripts directory we just made:

vi ~/.local/share/nautilus/scripts/convert_to_jpeg

Then, add the code. The following script converts all the files currently selected in Nautilus, and converts them to JPEG using the ImageMagick convert command:

#!/bin/bash

echo -e "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | xargs -i convert "{}" "{}.jpg"

Note that we are using a variable here called $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS. This contains a list of the full paths of all the files that were selected in Nautilus when we invoked the script. Two other useful variables provided are $NAUTILUS_SCRIPT_CURRENT_URI and $NAUTILUS_SCRIPT_SELECTED_URIS. (Update: Script is fixed to allow for files that have spaces in their names.)

3. Make the script executable

The final step is to make your script executable, so it will show up in the Nautilus context menu:

chmod +x ~/.local/share/nautilus/scripts/convert_to_jpeg

4. Test!

Now your script will appear in Nautilus. To test it out, select one or more files, right click, and choose Scripts > convert_to_jpeg.

A GIF of the convert_to_png Nautilus script in action

Voilà! If imagemagick is able to convert the format(s) you selected, you now have JPEG versions of them created in the same directory for you.

 

Providing Feedback from your scripts

Some of the scripts you create may benefit from providing some information back to the user. One of the easiest ways to do this in a bash script is using Zenity. Zenity allows you to provide a range of windows and alerts that pop up for the user, all invoked from the command line. It is also useful when you are trying to debug your scripts.

Other Ideas

  • Libreoffice offers the opportunity to print files using the command line. Using this, you could also create a script to print one or more Libreoffice documents without opening Libreoffice. The following is a sample script:
    #!/bin/bash
    
    libreoffice -p "$@"
  • convert files to PDF
  • convert video and music files
  • Show specific details on a file or directory (you can use Zenity to display the feedback)

Save

Save

Save

Save

Save

Save

Save



Read the whole story
iiska
50 days ago
reply
Oulu, Finland
Share this story
Delete

Password Rules Are Bullshit

3 Comments and 19 Shares

Of the many, many, many bad things about passwords, you know what the worst is? Password rules.

Let this pledge be duly noted on the permanent record of the Internet. I don't know if there's an afterlife, but I'll be finding out soon enough, and I plan to go out mad as hell.

The world is absolutely awash in terrible password rules:

But I don't need to tell you this. The more likely you are to use a truly random password generation tool, like us über-geeks are supposed to, the more likely you have suffered mightily – and daily – under this regime.

Have you seen the classic XKCD about passwords?

To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.

We can certainly debate whether "correct horse battery staple" is a viable password strategy or not, but the argument here is mostly that length matters.

That's What She Said

No, seriously, it does. I'll go so far as to say your password is too damn short. These days, given the state of cloud computing and GPU password hash cracking, any password of 8 characters or less is perilously close to no password at all.

So then perhaps we have one rule, that passwords must not be short. A long password is much more likely to be secure than a short one … right?

What about this four character password?

✅🐎🔋🖇️

What about this eight character password?

正确马电池订书钉

Or this (hypothetical, but all too real) seven character password?

You may also be surprised, if you paste the above four Unicode emojis into your favorite login dialog (go ahead – try it), to discover that it … isn't in fact four characters.

Oh dear.

"💩".length === 2

Our old pal Unicode strikes again.

As it turns out, even the simple rule that "your password must be of reasonable length" … ain't necessarily so. Particularly if we stop thinking like Ugly ASCII Americans.

And what of those nice, long passwords? Are they always secure?

aaaaaaaaaaaaaaaaaaa
0123456789012345689
passwordpassword
usernamepassword

Of course not, because have you met any users lately?

I changed all my passwords to

They consistently ruin every piece of software I've ever written. Yes, yes, I know you, Mr. or Ms. über-geek, know all about the concept of entropy. But expressing your love of entropy as terrible, idiosyncratic password rules …

  • must contain uppercase
  • must contain lowercase
  • must contain a number
  • must contain a special character

… is a spectacular failure of imagination in a world of Unicode and Emoji.

As we built Discourse, I discovered that the login dialog was a remarkably complex piece of software, despite its surface simplicity. The primary password rule we used was also the simplest one: length. Since I wrote that, we've already increased our minimum password default length from 8 to 10 characters. And if you happen to be an admin or moderator, we decided the minimum has to be even more, 15 characters.

I also advocated checking passwords against the 100,000 most common passwords. If you look at 10 million passwords from data breaches in 2016, you'll find the top 25 most used passwords are:

123456
123456789
qwerty
12345678
111111
1234567890
1234567
password
123123
987654321
qwertyuiop
mynoob
123321
666666
18atcskd2w
7777777
1q2w3e4r
654321
555555
3rjs1la7qe
google
1q2w3e4r5t
123qwe
zxcvbnm
1q2w3e

Even this data betrays some ASCII-centrism. The numbers are the same in any culture I suppose, but I find it hard to believe the average Chinese person will ever choose the passwords "password", "quertyuiop", or "mynoob". So this list has to be customizable, localizable.

(One interesting idea is to search for common shorter password matches inside longer passwords, but I think this would cause too many false positives.)

Also of note: only 5 of the top 25 passwords are 10 characters, so if we require 10 character passwords, we've already reduced our exposure to the most common passwords by 80%. I saw this originally when I gathered millions and millions of leaked passwords for Discourse research, then filtered the list down to just those passwords reflecting our new minimum requirement of 10 characters or more. It suddenly became a tiny list. (If you've done similar common password research, please do share your results in the comments.)

I'd like to offer the following common sense advice to my fellow developers:

1. Password rules are bullshit

  • They don't work.
  • They heavily penalize your ideal audience, people that use real random password generators. Hey guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
  • They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
  • Are often wrong, in the sense that they are grossly incomplete and/or insane, per the many shaming links I've shared above.
  • Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules".

2. Enforce a minimum Unicode password length

One rule is at least easy to remember, understand, and enforce. This is the proverbial one rule to bring them all, and in the darkness bind them.

  • It's simple. Users can count. Most of them, anyway.
  • It works. The data shows us it works; just download any common password list of your choice and group by password length.
  • The math doesn't lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password.
  • Accept that even this one rule isn't inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable. A 20 character password can be ridiculously insecure.
  • If you don't allow (almost) every single unicode character in the password input field, you are probably doing it wrong.
  • It's a bit of an implementation detail, but make sure maximum password length is reasonable as well.

3. Check for common passwords

As I've already noted, the definition of "common" depends on your audience, and language, but it is a terrible disservice to users when you let them choose passwords that exist in the list of 10k, 100k, or million most common known passwords from data breaches. There's no question that a hacker will submit these common passwords in a hack attempt – and it's shocking how far you can get, even with aggressive password attempt rate limiting, using just the 1,000 most common passwords.

  • 1.6% have a password from the top 10 passwords
  • 4.4% have a password from the top 100 passwords
  • 9.7% have a password from the top 500 passwords
  • 13.2% have a password from the top 1,000 passwords
  • 30% have a password from the top 10,000 passwords

Lucky you, there are millions and millions of real breached password lists out there to sift through. It is sort of fun to do data forensics, because these aren't hypothetical synthetic Jack the Ripper password rules some bored programmer dreamed up, these are real passwords used by real users.

Do the research. Collect the data. Protect your users from themselves.

4. Check for basic entropy

No need to get fancy here; pick the measure of entropy that satisfies you deep in the truthiness of your gut. But remember you have to be able to explain it to users when they fail the check, too.

entropy visualized

I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters. And that's what we do as of the current beta version of Discourse. But I'd love your ideas in the comments, too. The simpler and clearer the better!

5. Reject special case passwords

I'm embarrassed to admit that when building the Discourse login, as I discussed in The God Login, we missed two common cases that you really have to block:

  • password equal to username
  • password equal to email address

🤦 If you are using Discourse versions earlier than 1.4, I'm so sorry and please upgrade immediately.

Similarly, you might also want to block other special cases like

  • password equal to URL or domain of website
  • password equal to app name

In short, try to think outside the password input box, like a user would.

[advertisement] Building out your tech team? Stack Overflow Careers helps you hire from the largest community for programmers on the planet. We built our site with developers like you in mind.
Read the whole story
iiska
50 days ago
reply
Oulu, Finland
Share this story
Delete
3 public comments
chrisminett
49 days ago
reply
We need to check the last points (username, app name)
Milton Keynes, UK
wmorrell
51 days ago
reply
True story: work wants to roll out Microsoft Office 365, and I was one of the first trial users. I got a post-it with an 8 character password from the IT grunt tapped to be the AD admin. As is my habit, I immediately changed the password with a random one created by a password manager. The password was 20 characters. The change password form accepts the new password and prints a happy "password changed!" message. I log out, then try to log back in; the login page then informs me that the maximum … *maximum* password length is 16 characters and rejects my login. Okay … truncate it to 16, maybe the change form cut it off. Login fails. Go back to IT grunt to get a password reset, get a new 8-character password. Login fails. Reset again. Be very careful copying down password, very careful entering it back in. Login fails.
So, it turns out that there is no length validation on Office 365 password change forms, and going over the 16-character minimum mentioned nowhere on the page will *permanently* lock your account. 👍
expatpaul
51 days ago
Why is there even an upper limit? If the password is properly salted and hashed then only the hash should matter.
wmorrell
51 days ago
From what I found, it is some backward-compatible dependency thing with Active Directory syncing, which Microsoft has not cared enough about to fix. Possibly something with early Windows versions storing passwords as reversible hashes, and definitions of the protocols for remote logins defining a now-too-short field for passwords. The limitation could have made sense in the early 1990s, but then got carried forward far too long, and we are still stuck with it 25 years later.
expatpaul
50 days ago
Ah, I can see how that would happen. In my experience, many of the problems with Windows can be traced to poor early implementation that was never (or becomes increasingly difficult to) fix.
expatpaul
51 days ago
reply
Possibly the worst password rule is the one that demands you change your password on a regular basis. Either people will start writing down their passwords, or come up with a pattern that ensures their passwords are always easy to guess.
Belgium
wffurr
51 days ago
What's wrong with writing down passwords? A written copy is extremely useful, if you secure it the same way you do your money and credit cards, i.e. carry it in your pocket.
expatpaul
51 days ago
Point taken, wffurr. I was thinking more about the corporate environment which is where I usually see mad password rules like these. The number of times I have seen passwords on post-it notes, whichg are stuck somewhere convenient, is quite frightening.
expatpaul
51 days ago
That said, the best approach is to use a password manager to store randomly generated passwords. Of course, my current employer bans the use of password mangers.
HarlandCorbin
51 days ago
Must change password every 21 days. Cannot reuse last 50 passwords. **These** rules make my passwords less secure than they could be. I have given up generating passwords that I can reasonably type that follow the rules. I mean, 21 days?!?
expatpaul
51 days ago
21 days? Ouch! The worst I saw was every 30 days, and I know a number of people using a combination on month and year for their password.
HarlandCorbin
50 days ago
And the new password can only have (IIRC) one point of similarity with the previous one.
expatpaul
50 days ago
That's just painful. It's rules like that which are just asking everyone to write their password on the nearest available post-it note.
Aatch
50 days ago
That's weirdly strict. We have a change every 90 days and you can't use your last 2 passwords. That's it. Simple enough to rotate a handful of passwords 4 times a year.
chrisrosa
50 days ago
this one drives me crazy. the damn auditors eat password expiry up and are always pushing for less time. total bs.
mareino
50 days ago
There is a government personnel website I've used where (1) the average user logs in about 2x/year, (2) the password resets monthly.
WorldMaker
46 days ago
The NIST guidelines link in the post also strongly recommend against arbitrary password expiration. I sent the NIST document to my corporate IT when they changed password expiration rules just recently. It hasn't impacted any change, but at least I tried to talk sense to power.
expatpaul
45 days ago
@WorldMaker: I'm impressed that you tried to talk sense, but the main problem with large corporations is that they tend to adopt a checkbox approach to these things. People have to prove that they are doing _something_ about security; no-one ever asks whether what they are doing is actually useful.
WorldMaker
44 days ago
@expatpaul: Arguably as a software developer a part of my role is to evaluate and better the company's software. Even if that just means writing a ticket every few weeks to try to argue true industry best practices against fads and security theater. Of course, without a CTO title they don't have to listen to me, but I can hope they might at least read it. Even if they are hearing stupid crap from outside security consultants and terrible software vendors that should be destroyed for the betterment of the corporate world like Oracle. The only way we might see change is to keep talking sense to power and hope someone listens or promotes us until they have to listen.
chrisrosa
44 days ago
As long as companies want to do business with companies the require SOC2, HIPPA, SOX, etc. (not to mention their own compliance BS), it doesn't really matter. At least NIST is on board.
Next Page of Stories