[zheng]

First off, as others have said, disabling port 80 is a great way to handle this, I don't really care that much if I can see/use github the website for a few hours, but I'd be much more upset if I couldn't pull my code.

Secondly, I kind of like when big sites go down when I'm not in desperate need because it means a really nice aftermath write up is on the way. Can't wait to hear more about this one.

[mst]

> "disabling port 80 is a great way to handle this"

It's been a disaster for a bunch of people I know.

git is distributed by nature so they all had extra remotes they could use.

github's issues and other project metadata wasn't distributed, since that's github's alone.

So all of the friends of mine who are corporate github users who were using git in a distributed style (a minority of their overall customer base, I would suspect) are more screwed by the web app's absence than they would have been by a repository problem.

I suspect github made the right choice for their customer base overall, but I still find the anecdata interesting.

[kijin]

The web app is also available on port 443, which every "corporate github user" should have been using anyway.

[wfarr]

In fact, all HTTP access redirects to HTTPS for just about everything. And most modern browsers (recent versions of Chrome and Safari) that have accessed a website over HTTPS once happen to _prefer_ HTTPS by default for that site.

[adambard]

They didn't even disable https, so the site was still fully usable.

[huhtenberg]

> disabling port 80 is a great way to handle this

They got lucky. What would be a great way to handle it if next time it's port 21 or 443?

[zheng]

Like I said, disabling port 80 is a great way to handle this kind of attack. Those would obviously be trickier. I'm no network security expert, but I would assume that they are much more resilient to other attacks, as most protocols aren't as network intensive as TCP.