Not a great deal, usually. It just means that there will be a lot of folks writing a lot of code for what is likely to be of no benefit except to large corporate websites (since most of us don't meter our traffic by the byte).
... which can of course cause it to send you cached files you already have.
That seems like it would be relatively easy to solve. Your browser should send a manifest of resources previously cached from a given domain as part of the initial connection negotiation. Then, the server can just implement the cache policy itself and not resend anything that the browser already has.
SPDY's server hint mechanism is a poor hack, IMO, and does this exactly backwards. As a result, the latency savings are much less than they otherwise would be except in rare cases where the data being sent is fairly large and takes a long time to arrive. By contrast, if the browser sent a cache manifest during negotiation, the entire multiplication-of-round-trip-latencies problem would almost completely go away, because the server has to wait for the initial request before sending a response no matter what.
Badly. It does multiple transfers in a pipeline if the server supports it, or else it falls back to basic keep-alive if the server is believed to be broken.... The problems, however, are manifold.
First, the browser must ask for each piece. With a more modern protocol, the browser asks for index.html, and the server says, "Okay. Here's index.html, and oh, BTW, here are the eight hundred images, CSS files, and JavaScript resources that you'll need in order to render it. HAND." The benefit comes from not having multiple cycles of request, parse, request more, parse, request more, parse, etc.
Second, the connection can do only one thing at once. If the HTML content comes from a script (and thus may be generated relatively slowly), the browser might get a partial HTML page with a bunch of images, but unless it opens a second connection to the server, it can't request those images until the entire blob of HTML has arrived. The browser sets limits as to how many connections it will open to a single server at once, so as soon as you have more than a couple of connections in that "data partially sent" state, any other requests are blocked waiting for those requests to complete. Couple this with just enough packet loss and/or latency to cause degenerate TCP behavior, and you have a recipe for terrible performance.
By contrast, a protocol that can say, "Oh, I've just sent part of an HTML file, and it contains twelve IMG tags; I'm providing you with the images interleaved with the HTML data" does not have this problem. No new connections are required; the images get sent while the script is continuing to scream at the database, "Give me data!" And although packet loss still impacts the arrival of the end of the stream, at least you don't have a multiplicative effect as you would if each of the image requests begins until the end of the stream.
And so on. There are very good reasons for upgrading the protocol. With that said, IMO, using a binary format is unnecessary. You could just as easily send a text string that says "Stream: 1\nChunk-length: 4096\n\n" followed by 4096 bytes of data, a newline, and a similar blob for the next stream. The overhead difference is likely to be negligible proportional to the data.
Seriously. I wrote a basic web server with CGI support (with connection handling built around nc) in only a couple of hundred lines of shell script. HTTP is freaking mindlessly simple to parse (though I won't claim to have done so 100% correctly).
Put a 1 ms delay in every packet going across your router. See how it feels.
Given that the stated purpose for these protocol upgrades is to make HTTP work better for cellular networking users, who frequently experience latency measured in seconds, a one millisecond time difference is so completely buried in the noise so as to make it utterly moot. The real beneficiaries of these sorts of changes are big companies who pay for their bandwidth by the gigabyte... and even then, only if it makes the difference between a request fitting into one packet or getting fragmented.
That's still not a valid reason to refuse to allow compression. As I understand it, LZW lets you set aside a token (a "flush character") to tell the receiver to reset the compression dictionary to its original state. If the browser sends that token before and after any data that could potentially be altered by a third party (likely just the GET/POST query string and, where applicable, the POST body), you would still get most of the benefits of compression without the loss of security, unless I'm missing something.
Has the readability of TCP flags ever been a huge problem for anyone?
Of course not, but TCP is handled down in the kernel. For the most part, only those of us who have done kernel-level programming have ever had to deal with them directly. It requires a fair amount of work to get your hands on the raw packets. By contrast, HTTP is an application-layer protocol, which means that orders of magnitude more people have to write and maintain code compatible with it. It is relatively trivial to obtain raw HTTP stream data.
I'm not saying that this is a show-stopper for me or anything—it really isn't that important so long as the standard requires permanent backwards compatibility with earlier versions of the specification so that when we have to debug something hairy, we can manually send the old-fashioned query and get back a response in a human-readable format—but I really don't see how the infinitesimal performance benefit from binary headers is worth all the effort of rewriting all those server and client implementations.
On a poorly coded site this can amount to hundreds of kilobytes of data for every click the user makes.
I'd go one step further and say that ASP-based sites are almost by definition poorly coded. A well-coded site should not require the server to know anything about the state of the client. The client should maintain its state locally, and should use XHR to fetch precisely the data it needs in order to update the view. The old-style architectures where the server knows everything and provides entire pages full of content just doesn't make much sense anymore, at least for nontrivial sites.
I frequently get fairly close to the raw protocol, using curl, and have even been known to manually make HTTP requests in a telnet session on occasion. That said, I'm assuming a future version of curl would simply translate the headers and stuff into the historical format for human readability, making this sort of change fairly unimportant in the grand scheme of things.
That's true. And in my experience, people in the former group have a tendency to quickly rise to high positions in government and business, like CEOs and congresspeople, assuming they don't get caught, so finding a way to weed these people out early would benefit everyone.:-)
At least they chose an obviously fake alert. Imagine if they had announced a terrorist threat to a major sporting event. They could have easily caused a mass panic with thousands of casualties. This is why we must take cyber-security seriously. Specifically:
The community needs to continue beefing up vulnerability databases to make it easier for people to get alerts about software and hardware that they own and use, rather than generic warnings that contain dozens of products, 99% of which they don't care about. (That said, I do have to at least give CERT credit for finally making their email alerts useful instead of the useless "Click this link for an updated vulnerability summary" emails that they used to send out.)
Every college and university must make computer security classes mandatory for all CS and CE majors so that the systems they design are secure by default instead of defective by design.
Language developers must make common unsafe programming techniques impossible. For example, string taint support should be turned on by default, it should not be possible to remove that taint from a user-provided string, and it should be a fatal error for a tainted string to appear anywhere in the query string for a mysqli or PDO query.
Support for the base (non-parameterized) mysql library should be removed from all languages unless someone manually recompiles the libraries to include it, with a warning that the support will be removed entirely within two years.
And so on. Notice how none of these things involve secret government organizations monitoring exabytes worth of data each day to "protect" us.
There are still merely-self-interested insiders: It's practically a tradition for Mr. Sleazy McSales to abscond with all the customer data when he accepts a position with the competition, and his engineering counterparts to lift design docs and the like for the same purpose.
IMO, lifting contact info is just not a big deal, in much the same way that bringing your Rolodex with you has been the norm for decades. If your business has such poor customer loyalty that the mere knowledge of your customer list puts it in jeopardy, then your business should die to make room for more worthy competitors.
As for lifting engineering designs, if your competition does much of anything with those designs, they run the risk of running afoul of the law, and can get into serious trouble for it. That's why when Pepsi was offered Coca-Cola's trade-secret formulas, they reported the leaker to their competitor.
This is not to say that there isn't very short-term usefulness to keeping secrets about products that have not yet been released, but if you're really concerned about that, it is an easily solved problem: give all your employees a 12-month paid do-not-compete clause, in which they aren't allowed to work for your competition for a period of time, but you pay them as though they were still working for you. This eliminates that risk almost entirely, while still being fair to the workers.
That's not your data. There's a difference between the business's data (which is very hard to control usefully) and their customers' data, which by law must be very strictly access-controlled.
I haven't studied the actual hardware up close, but I'm assuming they're mostly fiberglass. If so, then sufficiently large masses must able to expand and contract as the temperature changes, or else they will break. Therefore, you likely have to leave a small gap and fill it with something that can compress (e.g. rubber seal). Unfortunately, when the rubber compresses, it comes out the top and bottom equally.
I suppose if the slides were made of metal, you could make the uppermost piece lap over the lower piece by an inch and then stop. This would make the joint sharp if you were going upwards, but because you're going downwards, it should not be. However, metal is a lot more expensive than fiberglass.
If that was all he released through the proper channels he could be termed a whistle blower.
What proper channel? No, seriously. The "proper channel" you speak of would almost certainly have asked his bosses if it was true. They would have trotted out the same half-truths that the government did when confronted by the media, and the "proper channel" would have accepted it. Rinse, repeat.
And at some point, the answer would have been, "Look, the AG says this has been vetted, and is legal," at which point the "proper channel" would be unable to proceed, no one would know that the government was spying on him, and he'd be back exactly where he was when he went to the press. Not to mention that there was a very real risk that he'd find himself losing access to the information after disclosing it to the "proper channel" to ensure that he did not disclose it further, making a full investigation impossible.
I'm not sure I see the point of going through such a channel first.
28 NAVAID Instrument Landing System Runway 28L Glide Path out of service started about 1 month ago ending in about 1 month
28 NAVAID Localizer Type Directional Aid Runway 28R Glide Path out of service started about 1 month ago ending in about 1 month
28 NAVAID Instrument Landing System Runway 28R Glide Path out of service started about 1 month ago ending in about 1 month
23 NAVAID Instrument Landing System Runway 28R Inner Marker out of service until Aug 22 23:59
20 NAVAID Instrument Landing System Runway 28R Category 2/3 Not Authorized started about 1 month ago ending in about 1 month
One rumor I heard was that ILS (or some portion of it) wasn't functioning on the runway the plane was landing on (28L) so the pilot was making a manual approach without the automated glidepath alerts he'd normally have.
Not a rumor. Go read the NOTAM (notice to airmen) list. It has been down for a month, and is expected to be down until August 22.
Except that right now, there's little to no ILS at SFO, as a result of government-mandated construction work to shift the landing zone inland (ironically, to prevent this exact situation), requiring the antennas to be relocated.
Slashdot Mirror
Not a great deal, usually. It just means that there will be a lot of folks writing a lot of code for what is likely to be of no benefit except to large corporate websites (since most of us don't meter our traffic by the byte).
That seems like it would be relatively easy to solve. Your browser should send a manifest of resources previously cached from a given domain as part of the initial connection negotiation. Then, the server can just implement the cache policy itself and not resend anything that the browser already has.
SPDY's server hint mechanism is a poor hack, IMO, and does this exactly backwards. As a result, the latency savings are much less than they otherwise would be except in rare cases where the data being sent is fairly large and takes a long time to arrive. By contrast, if the browser sent a cache manifest during negotiation, the entire multiplication-of-round-trip-latencies problem would almost completely go away, because the server has to wait for the initial request before sending a response no matter what.
Thoughts?
Badly. It does multiple transfers in a pipeline if the server supports it, or else it falls back to basic keep-alive if the server is believed to be broken.... The problems, however, are manifold.
First, the browser must ask for each piece. With a more modern protocol, the browser asks for index.html, and the server says, "Okay. Here's index.html, and oh, BTW, here are the eight hundred images, CSS files, and JavaScript resources that you'll need in order to render it. HAND." The benefit comes from not having multiple cycles of request, parse, request more, parse, request more, parse, etc.
Second, the connection can do only one thing at once. If the HTML content comes from a script (and thus may be generated relatively slowly), the browser might get a partial HTML page with a bunch of images, but unless it opens a second connection to the server, it can't request those images until the entire blob of HTML has arrived. The browser sets limits as to how many connections it will open to a single server at once, so as soon as you have more than a couple of connections in that "data partially sent" state, any other requests are blocked waiting for those requests to complete. Couple this with just enough packet loss and/or latency to cause degenerate TCP behavior, and you have a recipe for terrible performance.
By contrast, a protocol that can say, "Oh, I've just sent part of an HTML file, and it contains twelve IMG tags; I'm providing you with the images interleaved with the HTML data" does not have this problem. No new connections are required; the images get sent while the script is continuing to scream at the database, "Give me data!" And although packet loss still impacts the arrival of the end of the stream, at least you don't have a multiplicative effect as you would if each of the image requests begins until the end of the stream.
And so on. There are very good reasons for upgrading the protocol. With that said, IMO, using a binary format is unnecessary. You could just as easily send a text string that says "Stream: 1\nChunk-length: 4096\n\n" followed by 4096 bytes of data, a newline, and a similar blob for the next stream. The overhead difference is likely to be negligible proportional to the data.
Seriously. I wrote a basic web server with CGI support (with connection handling built around nc) in only a couple of hundred lines of shell script. HTTP is freaking mindlessly simple to parse (though I won't claim to have done so 100% correctly).
Port 666 UDP is officially registered to id Software for use in Doom.
Given that the stated purpose for these protocol upgrades is to make HTTP work better for cellular networking users, who frequently experience latency measured in seconds, a one millisecond time difference is so completely buried in the noise so as to make it utterly moot. The real beneficiaries of these sorts of changes are big companies who pay for their bandwidth by the gigabyte... and even then, only if it makes the difference between a request fitting into one packet or getting fragmented.
That's still not a valid reason to refuse to allow compression. As I understand it, LZW lets you set aside a token (a "flush character") to tell the receiver to reset the compression dictionary to its original state. If the browser sends that token before and after any data that could potentially be altered by a third party (likely just the GET/POST query string and, where applicable, the POST body), you would still get most of the benefits of compression without the loss of security, unless I'm missing something.
Of course not, but TCP is handled down in the kernel. For the most part, only those of us who have done kernel-level programming have ever had to deal with them directly. It requires a fair amount of work to get your hands on the raw packets. By contrast, HTTP is an application-layer protocol, which means that orders of magnitude more people have to write and maintain code compatible with it. It is relatively trivial to obtain raw HTTP stream data.
I'm not saying that this is a show-stopper for me or anything—it really isn't that important so long as the standard requires permanent backwards compatibility with earlier versions of the specification so that when we have to debug something hairy, we can manually send the old-fashioned query and get back a response in a human-readable format—but I really don't see how the infinitesimal performance benefit from binary headers is worth all the effort of rewriting all those server and client implementations.
I'd go one step further and say that ASP-based sites are almost by definition poorly coded. A well-coded site should not require the server to know anything about the state of the client. The client should maintain its state locally, and should use XHR to fetch precisely the data it needs in order to update the view. The old-style architectures where the server knows everything and provides entire pages full of content just doesn't make much sense anymore, at least for nontrivial sites.
And then there's the joke one of my coworkers wrote on his whiteboard: "I know a joke about UDP, but you might not get it."
I knew Jack Moréso, and HTTP, sir, is no Jack Moréso.
I frequently get fairly close to the raw protocol, using curl, and have even been known to manually make HTTP requests in a telnet session on occasion. That said, I'm assuming a future version of curl would simply translate the headers and stuff into the historical format for human readability, making this sort of change fairly unimportant in the grand scheme of things.
That's true. And in my experience, people in the former group have a tendency to quickly rise to high positions in government and business, like CEOs and congresspeople, assuming they don't get caught, so finding a way to weed these people out early would benefit everyone. :-)
At least they chose an obviously fake alert. Imagine if they had announced a terrorist threat to a major sporting event. They could have easily caused a mass panic with thousands of casualties. This is why we must take cyber-security seriously. Specifically:
And so on. Notice how none of these things involve secret government organizations monitoring exabytes worth of data each day to "protect" us.
IMO, lifting contact info is just not a big deal, in much the same way that bringing your Rolodex with you has been the norm for decades. If your business has such poor customer loyalty that the mere knowledge of your customer list puts it in jeopardy, then your business should die to make room for more worthy competitors.
As for lifting engineering designs, if your competition does much of anything with those designs, they run the risk of running afoul of the law, and can get into serious trouble for it. That's why when Pepsi was offered Coca-Cola's trade-secret formulas, they reported the leaker to their competitor.
This is not to say that there isn't very short-term usefulness to keeping secrets about products that have not yet been released, but if you're really concerned about that, it is an easily solved problem: give all your employees a 12-month paid do-not-compete clause, in which they aren't allowed to work for your competition for a period of time, but you pay them as though they were still working for you. This eliminates that risk almost entirely, while still being fair to the workers.
That's not your data. There's a difference between the business's data (which is very hard to control usefully) and their customers' data, which by law must be very strictly access-controlled.
Exactly. If an employer is doing nothing wrong, then at least long-term, it has nothing to hide. :-D
I so know what my next shell script should be.
Cost, I'd imagine.
I haven't studied the actual hardware up close, but I'm assuming they're mostly fiberglass. If so, then sufficiently large masses must able to expand and contract as the temperature changes, or else they will break. Therefore, you likely have to leave a small gap and fill it with something that can compress (e.g. rubber seal). Unfortunately, when the rubber compresses, it comes out the top and bottom equally.
I suppose if the slides were made of metal, you could make the uppermost piece lap over the lower piece by an inch and then stop. This would make the joint sharp if you were going upwards, but because you're going downwards, it should not be. However, metal is a lot more expensive than fiberglass.
What proper channel? No, seriously. The "proper channel" you speak of would almost certainly have asked his bosses if it was true. They would have trotted out the same half-truths that the government did when confronted by the media, and the "proper channel" would have accepted it. Rinse, repeat.
And at some point, the answer would have been, "Look, the AG says this has been vetted, and is legal," at which point the "proper channel" would be unable to proceed, no one would know that the government was spying on him, and he'd be back exactly where he was when he went to the press. Not to mention that there was a very real risk that he'd find himself losing access to the information after disclosing it to the "proper channel" to ensure that he did not disclose it further, making a full investigation impossible.
I'm not sure I see the point of going through such a channel first.
Statistically? Most Americans over 40. The people who don't are America's youth.
The second I heard about this, I went over to PPRuNe. Several of the pilots there mentioned it in the discussion thread about the accident.
Citation: takeoffaviationweather.com. The relevant bits:
KSFO
28 NAVAID Instrument Landing System Runway 28L Glide Path out of service started about 1 month ago ending in about 1 month
28 NAVAID Localizer Type Directional Aid Runway 28R Glide Path out of service started about 1 month ago ending in about 1 month
28 NAVAID Instrument Landing System Runway 28R Glide Path out of service started about 1 month ago ending in about 1 month
23 NAVAID Instrument Landing System Runway 28R Inner Marker out of service until Aug 22 23:59
20 NAVAID Instrument Landing System Runway 28R Category 2/3 Not Authorized started about 1 month ago ending in about 1 month
Emphasis mine.
Not a rumor. Go read the NOTAM (notice to airmen) list. It has been down for a month, and is expected to be down until August 22.
Except that right now, there's little to no ILS at SFO, as a result of government-mandated construction work to shift the landing zone inland (ironically, to prevent this exact situation), requiring the antennas to be relocated.