Varnish Author Suggests SPDY Should Be Viewed As a Prototype

An anonymous reader writes "The author of Varnish, Poul-Henning Kamp, has written an interesting critique of SPDY and the other draft protocols trying to become HTTP 2.0. He suggests none of the candidates make the cut. Quoting: 'Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic.'"

Comments

While I hate the transfer syntaxes we have

[scorp1us]

Parsing a HTTP session with multi-part mime attachments using chunked encoding is murderous. Now true, many people don't have to worry about this, but the fact is the protocol leaks like a sieve. For instance, you can't send a header after you've entered the body of the HTTP session. You can't mix chunked-length encoded elements with fixed content-length elements with HTTP1.1. Once you've sent your headers and encoding, you're screwed. The web has a solution - AJAX, but then you need JavaScript.

I'd be all for something new. I'd suggest base it on XML with a header section and header-element to get the transfer started then accept any kind of structured data including additional header elements. With this, you can still use HTTP headers for back-wards compatibility, but once recognized as "HTTP 2.0" the structured XML can be used to set additional headers, etc. With the right rules, you can send chunks of files or headers in any arbitrary order and have them reconstructed.

Re:While I hate the transfer syntaxes we have

[Skapare]

If you substitute JSON (or something like it with equal or better simplicity) for XML, then I might go along with it.

Re:While I hate the transfer syntaxes we have

[tigre]

Did you really just say XML?

Re:While I hate the transfer syntaxes we have

[dave420]

XML? Cute.

Re:While I hate the transfer syntaxes we have

[laffer1]

XML is too big. If anything, we need to compress the response not make it ten times larger. The header thing can be annoying at times, but it's important to know what you're going to send the client anyway. You must figure it out by the end of the document, why not at the beginning? Many files have a header including shell scripts, image files, BOM on XML documents or even the xml declaration. it's common in the industry.

AJAX doesn't solve the real problem. If anything it necessitates making responses smaller and faster. We have to do many connections and deal with the overhead of that. Pipelining can help some, but if we continue down this road, we must make the protocol more efficient. XML is the opposite of that goal. I don't agree with anything less compact than what we have now, but you could at least argue for JSON as it's already supported by browsers and much faster to parse.

As there are vastly different goals with the next generation of HTTP, I think it's best not to rush into anything. We'll be stuck with this new protocol. If it doesn't take off, it's just a hassle and if it does, it could be devastating to the internet if it's bloated or doesn't solve any real problems. I don't always agree with PHK, but he has a point that the current proposals do not solve all current or future issues. HTTP must be extendable, backward compatible, work with proxy servers, and allow for the continued growth of the internet. HTTP's lack of state is a problem for many of us now, but it was a feature in the early days. It made the protocol light weight and fast at a time when internet connections were slow. Cookies are abused. Many are created. I don't think adding state to the protocol is going to solve the underlying problem that developers store too much crap in it. Only a session id is necessary. Everything else should be stored server side or in a host page. A nice addition might be to limit where cookies are sent/received from beyond the same domain. That would take away the overhead of sending cookies for every image file, ajax request, etc. They're not always necessary. This can be worked around with a separate domain for images, but it's a hassle to setup.

I think some people have forgotten KISS. Keep it simple, stupid. Seems like everything is getting more complex only to force us back into what we were trying to get away from to begin with. Take NoSQL. Most people are still going strong with map reduce, yet google has been moving away from it. They're now trying to store indexes and incrementally update them. Gee what does a relational database server do.. it has indexes that get UPDATED. They're trying to reinvent SQL and they don't know it. Similarly, a bunch of cruft is getting added to the HTTP protocol and that will stay with us for a long time. Get it wrong and we end up with NoSQL all over again. NoSQL solves a few problems and creates others. It has use cases. HTTP on the other hand has to work for everything. It's critical it's done right.

Re:While I hate the transfer syntaxes we have

[Anonymous Coward]

XML (or the proposed JSON) isn't a good way to encode computer communications. Why not use a simple extendible binary encoding instead? If a human wants to read the communication for debugging or something else it would be easy to translate to a human readable format instead at human speeds. The computer would crunch through the binary coded format several times faster than optimized text parsing code (most such code isn't optimized).

Re:While I hate the transfer syntaxes we have

[DamonHD]

"You must figure it out by the end of the document, why not at the beginning?"

Because in many reasonable cases you don't know the final outcome when you've produced the first byte of the response, for example streamed on-the-fly-generated pages possibly with on-the-fly gzip encoding. The user gets to see useful output sooner, and the server can more easily cap peak resources, by streaming/pipelining and lazy eval. Like SAX rather than DOM.

Rgds

Damoner

Re:While I hate the transfer syntaxes we have

[spike2131]

I love JSON, but XML has the advantage of being something you can validate against a defined schema.

Re:While I hate the transfer syntaxes we have

[Skapare]

And what do you do when something does not validate? Kick the guy who typed it in manually? Oh wait, what if it was generated by a program?

The whole schema thing in XML is one of the things that makes it suck. Just write the data correctly in the first place and discard anything that doesn't make sense to the application.

Re:While I hate the transfer syntaxes we have

[Skapare]

s/Cute/Ugly/

XML is for marking up documents, not serializing data structures.

Now suppose we make HTTP based on XML. During the HTTP header parse, we need the schema. Fetch it. With what? With HTTP. Now we need to parse more XML and need another schema we have to get with HTTP which then has to be parsed ...

XML is not for protocols. JSON is at least more usable. Some simpler formats exist, too.

Re:While I hate the transfer syntaxes we have

[i_ate_god]

and whats wrong with Key: Value; Value; Value anyways?

Re:While I hate the transfer syntaxes we have

[jimmifett]

Ideally, you give the schema to the other side and they can validate the message before sending to you, catching possible errors there. You validate against same schema on your side as a safety net to week out junk data and messages from users that don't validate. It also allows you to enforce types and limitations on values in a consistent manner.

JSON is good for quick and dirty communications when you are both the sender and the consumer of messages and can be lazy and not care too much about junk data.

Both have their uses, but you have to know when to use which.

Re:While I hate the transfer syntaxes we have

[LO0G]

Yeah, maybe something like ASN.1.

Oh wait....[1]

[1] If you don't get this, you've never actually dealt with ASN.1.

Re:While I hate the transfer syntaxes we have

[mangobrain]

When it doesn't validate, you reject it. Or, in the case of a replacement for an "extensible" protocol, you do something more subtle - such as, accept something which is well-formed XML but contains unrecognised tags, by skipping over the unrecognised tags. Much as is done in HTML itself.

Once you've written a few programs which accept data from the public internet, you come to greatly appreciate the value of protocols whose syntax is easy to parse, and whose semantics are simple to understand. The simpler the parsing code, the less likely it is to contain exploitable bugs; the simpler the semantics, the easier it is to write standards-compliant logic, and have a wide range of client & server implementations which interoperate happily. HTTP in its modern form - i.e. augmented over the years with such features as persistent connections, pipe-lining, chunked encoding, multi-part bodies, compression, cookies & caching - is neither easy to parse, nor easy to understand once parsed. It needs to be taken out and shot, along with this whole laissez-faire attitude to standards compliance & well-formed-ness which permeates web standards.

Re:While I hate the transfer syntaxes we have

[Darinbob]

XML is a ridiculous format for this. It is bulky. It is intended to be human readable which means it is much llnger than protocols intended for machine readability. I can't figure out why everyone seems to think XML is the magic bullet to use everywhere. You dont neeed schemas for this, and if you did XML's method is really rotten anyway.

Re:While I hate the transfer syntaxes we have

[Carewolf]

Nothing, what is wrong with the MIME syntax used in HTTP?

The actually implementation and use may suck, but it could be cleaned to something more consistent without throwing everything else away as well.

Btw, You get almost all the speedup SPDY provides by just using HTTP 1.1 and pipelining. Only reason it is not done more is because it is hard to predict if it will be supported probably, but you could make that a requirement for HTTP 1.2 for instance, solving the problem.

Re:While I hate the transfer syntaxes we have

[Viol8]

Wish I had points to mod you up. So true!

Re:While I hate the transfer syntaxes we have

[A bsd fool]

I agree with the parsing nightmare, though XML is not the right answer either.

Transport needs encryption, authentication, and compression. Internally, the data can be handled by something similar to inetd+tcpmux.

1. SCTP w/ default-persistent connections for the transport.
2. PK signing of data to verify authorship, replacing SSL
3. Mandatory compression
4. A generic, extensible, data envelope used to hold the actual goodies, with a few well defined but generic header fields.

This gets rid of most of the problems that currently exist with TCP, allows efficient proxying and reverse proxying, and wastes fewer resources. Encryption at the transport layer means webservers in a virtual hosting environment no longer have to figure out what key to use before they know the target host. Signing data means the stream can be authenticated with existing SSL certificates and the CA infrastructure.

The data envelope would have a minimum number of headers. The envelope types, provided by client and server plugins, could be as simple as a datagram transport for "text/plain" to handle the bulk of existing websites, or as complex as an "application/webdav" handler for remote publishing, or "application/vcr" for interactive a/v media. If the overall protocol is thought of similar to TCPMUX where channel IDs are used instead of tcp/udp ports, we get everything we need, "forever".

The single pre-defined envelope type is simply used to exchange a list of supported envelope types by both ends. This is the only part of the protocol that would continue to be "string based", so no central authority is needed to assign and manage a mapping between envelope types and IDs

Re:While I hate the transfer syntaxes we have

[sydneyfong]

Except that it is impossible to design a validation scheme that covers all useful cases without resorting to designing a programming language.

And when you get to that point, why not just write the application code to validate in the first place? Why is it so hard to write a "schema validation" for JSON data? The fact that the designers of JSON didn't overengineer the feature into the spec doesn't mean it's hard to do....

Re:While I hate the transfer syntaxes we have

[Johann Lau]

Some headers definately have to come first, since they pretty much indicate what the rest even means. But ETags for example... it would be wonderful to be able to send that stuff last... ... but I don't think I'd be willing to cram fucking XML into packets just for that (not that there is any connection between the two, referring to the root of this thread). Fuck human readability, seriously... it has it's place but it's also highly, and mindlessly, overrated. Define it well and compact, and then you can still create viewers that turn the binary stuff into human readable things. What a concept!

For example, why do we send "status xxx: blah di bluh", instead of simply a two byte integer? Even respecting "has/had to be handled by systems which only do ASCII", it still should be "status: xxx", period, nothing more. I'm a complete noob, but even I have heard of DRY. If you want the string so badly, have a lookup table somewhere, instead of sending those strings around all the time... sorry for the rant, this stuff makes my blood boil :D

It's not like any of us can read ASCII without tools, either, nobody of us senses the magnetic patterns on the harddrive directly... so that "human-readable" is kind of a fucking joke. I mean, I know what it means, and it has merit to some extent, but still... it's also kinda dumb.

Re:While I hate the transfer syntaxes we have

[bill_mcgonigle]

The whole schema thing in XML is one of the things that makes it suck

because...

Just write the data correctly in the first place

which you can't count on from Internet clients

and discard anything that doesn't make sense to the application

Which is what schema validation does for you (securely) without having to write any code.

Re:While I hate the transfer syntaxes we have

[badkarmadayaccount]

XMPP?

Re:While I hate the transfer syntaxes we have

[badkarmadayaccount]

EBML?

Re:While I hate the transfer syntaxes we have

[badkarmadayaccount]

EBML

his criticism is not true in practice

[Chrisq]

He says:

For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ...

It seems to me that routing based on header is doing entirely the wrong thing. In any case, according to wikipedia:

TLS encryption is nearly ubiquitous in SPDY implementations

Which rather makes routing on content infeasible (OK you can forward route behind the SSL endpoint, but this doesn't seem to be what he's talking about)

Re:his criticism is not true in practice

[Mad Merlin]

TFA is talking about in reverse proxies (of which Varnish is one of many), which are very commonplace. In fact, you're seeing this page through (at least) one, as Slashdot uses Varnish.

Re:his criticism is not true in practice

[Short Circuit]

Routing based on header is the kind of thing you'd do in an accelerator proxy. You receive the request, look at the headers and perform actions based on those headers. Forwarding the request on to another host is an example of routing.

Re:his criticism is not true in practice

[Chrisq]

TFA is talking about in reverse proxies (of which Varnish is one of many), which are very commonplace. In fact, you're seeing this page through (at least) one, as Slashdot uses Varnish.

Publicly cached data is outside SPDY's use-case. It is aimed at reducing latency, and its main target is rich "web application" pages. Now it may well be possible to design a protocol that supports caching as well as reduced latency, but this is not what SPDY was designed to do.

Re:his criticism is not true in practice

[kasperd]

It seems to me that routing based on header is doing entirely the wrong thing.

But that is something you need to support as long as multiple domains are hosted on the same IP address. Lots of things gets easier if you can have a separate IP address for each domain you want to host. But there has been a shortage of IP addresses.

However there is a solution. You just have to move to IPv6, then you will no longer have a shortage on IP addresses. So what if some people find themselves in a situation where they cannot deploy SPDY on IPv4 (because of limitations in their proxies)? I don't see how that is a bad thing. They can keep using plain HTTP for IPv4 users and SPDY for IPv6 users, where there is no need to host multiple domains on a single IP address.

You might think it is a problem to have this difference between the IPv4 deployment and the IPv6 deployment. It is not a problem, it is a little bit of extra work, but any transitioning is a little bit of extra work. For any domain where you want to have dual stack support, you have to host the IPv4 and IPv6 version of the site on different IP addresses (that's sort of obvious, but needs to be pointed out to make the rest of the argumentation clearer). You can make your two (or more) domains resolve to the same IPv4 address, which is your HTTP proxy, additionally you can make the domains resolve to different IPv6 addresses, which are routed either directly to webservers or through some loadbalancer. You don't need to ever route the IPv6 addresses to the HTTP proxy, it can be routed to a load balancer that only knows TCP and none of the higher levels.

IPv4 support doesn't have to be a design goal in a new protocol designed today. Before a new standard can be agreed upon another continent or two will have run out of IPv4 addresses. There may still be other arguments against SPDY.

Re:his criticism is not true in practice

[Skapare]

It's more than just caching, these days. It's also about sending the requests to the appropriate server. For example, if you can send the requests of a logged in user to the same server or group of servers, it's easier to manage session state (each of 10000 servers holding 400 session states, instead of 10000 servers having to access a centralized store of 4000000 session states).

One thing a new protocol could do to better manage that is, after session authentication, tell the client another IP address and/or port to use so that subsequent requests go to a session group partition, which better distributes the load without having so large a gauntlet of layer 4+ smart session routers.

Or better yet, just hold the session up for as long as the user is present and using the service. First, think VNC. Then think replacing VNC with something smart.

Re:his criticism is not true in practice

[jbolden]

That's a really good idea! Make the HTTP shift coordinate with the IPV4/IPV6 shift and then we can assume 1 domain per IP. I'm having a tough time seeing how that breaks down. Any mods out there should mod you up for best idea of the day.

Re:his criticism is not true in practice

[toejam13]

It seems to me that routing based on header is doing entirely the wrong thing.

But that is something you need to support as long as multiple domains are hosted on the same IP address.

In the load-balancing world, this is known as "Layer 7 routing" and it is quite a handy feature. It also goes well beyond just HTTP HOST headers. The User-Agent header is probably the most useful as you can route clients based on browser type or version, operating system and language. I use this one a lot for forwarding clients to a web_css_pool and web_nocss_pool (looking at you, IE6).

Re:Google only recommends SPDY with SSL/443

[Short Circuit]

That's been fixed with TLS+SNI, which has broad support. SSL (as opposed to TLS) should be effectively dead as a support requirement by now.

interesting but flawed

[certain death]

So, because you would have to design new security tools and think a different way in order to make it sure, does that make it flawed? Does this mean we are no longer free to innovate unless it fits into some mold? That is just stupid. If someone comes up with a new way of doing things, put on your REAL security hat and come up with a way to secure it, don't just spread FUD about how it is BAD!!

Re:interesting but flawed

[fast turtle]

so you have the trillion pounds of latium to upgrade all of the routers on the internet? Good, then give me 5000 pounds worth so I can finally get the damn router/file/printer server for my household and provide the 100 million pounds for my ISP to get off their asses and upgrade to Docis3 and IPv6 tomorrow or STFU and Get off my lawn

Rethink HTTP with something else

[Skapare]

Much of what the web has become is no longer fitting the "fetch a document" model that HTTP (and GOPHER before it) are designed to do. This is why we have hacks like cookie managed sessions. We are effectively treating the document as a fat UDP datagram. The replacement ... and I do mean replacement, for HTTP, should integrate the session management with it, among other things. The replacement needs to hold the TCP connection (or better, the SCTP session), in place as a matter of course, integrated into the design, instead of patched around as HTTP does now. With SCTP, each stream can manage its own start and end, with a simpler encryption startup based on encrypted session management on stream 0. Then you can have multiple streams for a variety of serviced functions from nailed up streams for continuous audio/video, to streams used on the fly for document fetch. No chunking is needed since it's all done in SCTP.

Re:Rethink HTTP with something else

[broken_chaos]

That would be great, ideally (aside from maybe problems with it being absurdly over-engineered).

But it would be really hard to make it catch on. You'd need to manage support for 'traditional' HTTP and the new protocol in all clients, servers, *and* web applications. Because do you really think Microsoft would backport support into old versions of Internet Explorer that people are still using for some god-unknown reason?

Internet Explorer on Windows XP

[sgent]

According to the link, IE on Windows XP does not support TLS+SNI -- including IE 8.

Until this is fixed or sufficient number of people migrate to a newer OS, TLS+SNI is still not viable for most websites.

Re:Internet Explorer on Windows XP

[Short Circuit]

By the time a replacement of HTTP 2 is standardized, XP will be fully out of support. I get flamed whenever I say this, but it will be time to let XP die. I'm considering replacing my grandmother's box with an ASUS Transformer, as that'll handle all of her needs. (*And* the rest of my family won't say 'we don't know how to reboot the router because we don't know how to use the Linux netbook you set her up with.) Quickbooks runs on Vista and Win7. Tools and other things which require Windows XP are becoming scarcer, and workarounds and alternatives are becoming cheaper.

Eventually, XP will be like that DOS box that sits in some shops...used only for some specific, very limited purposes. Any shop cheaping out and still using it in lab environments (such as call centers) can work around it by installing a global self-signed cert and using a proxy server to rewrap SSL and TLS connections. Yes, this is bad behavior. So is continuing to use XP. At some point, the rest of Internet needs to move on.

Re:Internet Explorer on Windows XP

[Short Circuit]

What is your plan to make it happen? Will you be breaking in to people's homes and replacing their PCs?

Nobody has to make anything happen that isn't already either planned (Microsoft will stop supporting it) or physically inevitable.

Hardware will die. Software will get screwed up. Installation media will be missing. It will become cheaper for the 'family tech guy' to get his parents something newer or different as a replacement. There will be die-hards who will want to stick with Windows who will refuse to change. Those die-hards are outside the demographic of the vast majority of website maintainers.

So it went with Amiga, Commodore64, DOS, Win3.1, OS/2, Win95, Win98, IPX, token ring, Linux ipchains, VAX. DEC Alpha. So it goes. So it shall go.

When you are done, you should make everyone stop smoking and end poverty.

Heh.

Re:Internet Explorer on Windows XP

[cerberusss]

Just three years ago, Asus was still selling the EEE box, an Intel Atom powered PC. Because of the Vista fiasco, it still got a factory install with Windows XP.

Personally I agree with you but a lot of people are going to be without an upgrade path.

Re:Internet Explorer on Windows XP

[Short Circuit]

The sad thing about those PCs is that they're not going to be able to keep up with the increasing JS loads on websites. Chrome on my "Intel(R) Pentium(R) CPU B940 @ 2.00GHz" occasionally has difficulty. They'll get replaced.

Delenda est.

[Anonymous Coward]

Then it cannot replace HTTP and should be withdrawn, or it's been wrongfully sorted in under "HTTP/2.0 Proposals"

The IETF HTTPbis Working Group has been chartered to consider new work around HTTP; specifically, a new wire-level protocol for the semantics of HTTP (i.e., what will become HTTP/2.0), and new HTTP authentication schemes.

Re:Delenda est.

[Chrisq]

Then it cannot replace HTTP and should be withdrawn, or it's been wrongfully sorted in under "HTTP/2.0 Proposals"

The IETF HTTPbis Working Group has been chartered to consider new work around HTTP; specifically, a new wire-level protocol for the semantics of HTTP (i.e., what will become HTTP/2.0), and new HTTP authentication schemes.

Good point - unless there are particular reasons that a "niche protocol" for highly interactive sites is better than a general purpose one then a replacement that covers all uses should be covered. In fact I have come round to agreeing with TFA: "SPDY Should Be Viewed As a Prototype"

Re:Delenda est.

[tibman]

Isn't it a superset?

HTTP wouldn't pass muster

[khipu]

If someone proposed HTTP today, it wouldn't pass muster by these experts either. And I doubt that any of these new protocols really would make much of a difference anyway. The infrastructure has been built around HTTP, everybody knows how to compress it and everybody knows how to deal with the kind of multiple connections that it requires. If anything additional is really needed, it could be expressed as hints to the server and the intermediate infrastructure without starting from scratch.

Re:HTTP wouldn't pass muster

[Skapare]

SCTP sessions give you multiple streams to do anything you want in them. And once you have encryption established in stream 0, a simple key exchange is all that is needed encrypt the other streams. You can do fetches in some streams while others are doing interactive audio/video streaming. And that's all done within one session as the network stack, and session routers, see it.

Re:HTTP wouldn't pass muster

[Viol8]

"If someone proposed HTTP today, it wouldn't pass muster by these experts either."

And with good reason. Berners-Lee might have invented the web as we know it but like all first attempts (yes I know about hypercard and all the rest , they weren't networked!) it could really do with some serious improvement. Unfortunately the best solution would be to bin it and start again but its way to late for that so its make do and mend which almost always ends up in a total mess. Which is we what we have today.

Re:HTTP wouldn't pass muster

[jandrese]

The flipside of this is that a lot of the proposals to replace HTTP suffer badly from the second system effect, where the protocol designer decides to add proper support for all of the edge cases and ends up with a protocol that is gigantic and difficult to implement.

Re:HTTP wouldn't pass muster

[jbolden]

New protocols don't go through committees they just happen. That's the great thing about using a generic TCP/IP or UDP/IP base. New protocols prove themselves by finding a market; protocol revisions prove themselves by finding a consensus.

Re:HTTP wouldn't pass muster

[khipu]

HTTP has persistent connections for that. How do you propose to reduce latency even further?

Re:HTTP wouldn't pass muster

[jbolden]

Reread my original post. The protocols imposed by committee are those to fulfill an already existing need, i.e. they generate a consensus. Something like the revision to HTTP falls into the second group while the original HTTP was in the first. The HTTP revision protocol is that kind of protocol where Google is trying to drive the other big players towards adoption.

Oh yes XML, that efficiently parsable mess

[Viol8]

As a static data format its just about passable, but as a low overhead network protocol??

Wtf have you been smoking??

Re:Oh yes XML, that efficiently parsable mess

[Skapare]

XML is for marking up documents. Our problem with HTTP is that it is stuck in the legacy document model. Today we need streams, and optimization of sessions. XML would just be the markup of documents we might want to choose to fetch over those streams. Notice that audio/video/media containers are not based on XML, and never should be.

Re:Oh yes XML, that efficiently parsable mess

[Rob Riggs]

Wtf have you been smoking??

My guess: java beans.

Obligatory

[Meneth]

This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men"

Half the human race is middle-men, and they don't take kindly to being eliminated.

IE on XP, and Android 2.x too

[tepples]

So what should operators of small web sites do in the 21 months between now and when Microsoft agrees to let XP die? Now that IPv4 addresses have become scarce, and home ISPs still haven't been pushing IPv6, shared hosting companies are able to charge double for the dedicated IP addresses needed to run SSL 3.0. Besides, Android 2.x devices are still being sold, and their SSL stack doesn't support SNI either.

Re:IE on XP, and Android 2.x too

[Short Circuit]

If you think home ISPs haven't been scrambling to catch up on IPv6, you haven't been paying attention! Comcast is rolling it out right now. DSL providers are deploying 6rd. Mobile providers are deploying. Within a year, most end-users (in the US) will have access to IPv6 from their ISP. Within two years, most end-users will have replaced their non-IPv6 CPEs with ones which support IPv6. But IPv6 isn't the only solution to the problem, either.

Right now, most small website operators should avoid TLS if they only have static content. Otherwise, they need to make a decision between supporting XP and shelling out for a dedicated IP. Me, I'd probably drop support for XP, and let the end-user click through a cert warning if that's what they're inclined to do.

How much more per month are we talking about for a dedicated IP, anyway? I know how you'd set up joe random guy with a dedicated IPv4 address using a proxy server on a $5-7/mo VPS. Seems cheap to me, especially compared to what joe already spent to get a valid SSL cert.

As far as Android...a number of websites are pushing their users to use simple apps instead of the Android browser. As a user, this annoys me, as my LG-509 doesn't have much space unless I root it and clean it...but I can see how it offers a better interface to the server, and how it changes authentication and connectivity concerns.

Re:IE on XP, and Android 2.x too

[jandrese]

Within a year, most end-users (in the US) will have access to IPv6 from their ISP.

You sir, are an optimist. I applaud Comcast's deployment of IPv6, but the rest of the industry is still dragging their heels quite badly.

Re:IE on XP, and Android 2.x too

[Short Circuit]

Comcast is deploying native. AT&T is deploying 6rd. I hear TWC is also deploying native. Also, someone on the east side of Michigan went live with IPv6 a couple months ago and asked some questions in one of the mailing lists I'm on. I can't find the message now, though.

Re:IE on XP, and Android 2.x too

[allo]

when your page is important, the user will use a browser which is supported.
Imagine google only working with sni. How long will it take until no one uses IE8 anymore? Only a few days, and even the dumbest has found a friend who can download him a real browser.

Re:IE on XP, and Android 2.x too

[shutdown -p now]

So what should operators of small web sites do in the 21 months between now and when Microsoft agrees to let XP die?

Microsoft has been actively trying to bury XP for three years now by removing support for it from newly release products. Extended support does not really have anything to do with it, it's just a contractual obligation, not an invitation for people to keep using XP.

Re:IE on XP, and Android 2.x too

[allo]

you see, on a small sample.
Make it a large sample, as all the google users. the news pages will have big articles, computer magazins will title with this story "how to use google with XP", everyone will know, that everyone other has the same problem, and soon the solutions will emerge, which are rather easy: get someone to install another browser. For some people it will be an insider tipp, and some may need help of their more technical friends, but they will find the solution.

Re:Reminds me of IPP

[Skapare]

That's what you get when someone designs a protocol and then someone ELSE decides to change it in different ways of thinking. If the first one was well designed, changes should end up looking like they were part of the original. If the first one was poorly designed, make a whole new one.

JavaScript schema

[tepples]

JSON can also be validated against a schema, where the schema consists of a JavaScript file implementing isValid(parsed_object).

Re:JavaScript schema

[FrangoAssado]

That seems great, but then to validate against the schema you must have a full JavaScript interpreter (or almost full, depending on how much you're willing to restrict what can be used in the isValid function). Not to mention that, this being JavaScript, a lot of schemas would end up being a mess, which would defeat half of the purpose of a schema -- being a human-readable documentation of the data format.

Schema validation is a very clear example of a situation where it's not good to have a Turing-complete language. There is a proposal for a JSON schema language (where schemas are themselves JSON documents). Apparently there's not much interest, though.

zip file support

[Twillerror]

Wouldn't it be better to have the browser support zip/tarball path.

Now

  would look thru the zip file.

I suppose there could be some security issues here, but it seems like it would be easier than chunking protocols if not much faster.

Further ...

Now we've got cached apps as well.

Re:zip file support

[raynet]

Nah, it would be much better if we could use rsync:// instead of http:/// it would handle nicely partial downloads, compression, slightly changed files etc.

XML? In the name of ${DEITY:-XENU}, Why?

[luis_a_espinal]

I'd suggest base it on XML with a header section and header-element to get the transfer started then accept any kind of structured data including additional header elements.

Haven't we learned enough already from industrial pain to stay away from XML? JSON, BSON, YAML, compact RELAX NG, ASN.1, extended Backus-Naur Form. Any one of them, or something inspired by any (or all) of them, that is compact, unambiguos (there should be only one canonical form to encode a type), not necesarily readable, possibly binary, but efficiently easy to dump into an equally compact readable form. Compact and easy to parse/encode, with the lowest overhead possible. That's what one should look for.

But XML, no, no, no, for Christ's sake, no. XML was cool when we didn't know any better and we wanted to express everything as a document... oh, and the more verbose and readable, the better!!(10+1). We really didn't think it through that much back then. Let's not commit the same folly again, please.

Re:XML? In the name of ${DEITY:-XENU}, Why?

[SuricouRaven]

XML has many good uses.

This is not one of them.

Re:XML? In the name of ${DEITY:-XENU}, Why?

[Anonymous Coward]

XML has many good uses.

It's just that none of them involve computers.

Re:XML? In the name of ${DEITY:-XENU}, Why?

[luis_a_espinal]

XML has many good uses. This is not one of them.

Any text encoding has many good uses. And XML many good uses stem from the fact that... it is used, not because of its intrinsic qualities.

There is a reason why configuration files are moving away from XML. There is a reason why over-http data exchange protocols and RPC/messaging mechanism are moving away from XML (or at least from WS-*). It was just a stupid pipe dream to represent everything as a document. ZOMG, HTML is just SGML, so the next evolutionary step... for everything... must be.... (cue drums)... XML!

I was once one of those completely clueless people who thought so. You need something? XML! You need to configure something? XML? You need to store data? XML! You need a serialization protocol? XML! You need to specify name/value pair configuration parameters? XML! You need to externalize workflow logic? XML! You need to represent math equations? XML... oh noes, even worse, MathML!!!

Nah, XML-RPC is too primitive, let's throw everything and the kitchen sink in it for corner case problems that most people never face, let's call it WS-*. What do we use? XML! Say with me! XML!

Think otherwise? Name me 2-3 cases where XML fits a role where something else, say, JSON or ASN.1 fails to a degree that makes XML the better alternative.

Re:XML? In the name of ${DEITY:-XENU}, Why?

[SuricouRaven]

XML has the advantage of simple parsing. For example, I made a NZB fetcher - libxml did all the hard work, and even without that I could have extracted all the information I needed with nothing but a few regexes. It's ideal for that - it needs to hold only text data, and the object it stores is itsself made up of smaller objects made of smaller objects. So XML does have it's uses, but I agree that it is overused. For that matter, so are databases in general - how many applications do you find using a database, even something light like NoSQL, when a flat file would be more suitable?

Re:Reminds me of IPP

[Anonymous Coward]

I was the member of the IETF committee that proposed the standard (while working for Microsoft), and I agree its not very good but I can tell you that getting standards through various bodies is more politics than technology. Late in the cycle we tried to change it to XML but people thought we (MS) were playing mind games with the committee so the idea was abandoned

Why aren't people using SPDY, anyway?

[edxwelch]

HTTP 2.0 is not going to happen for a long time. SPDY is here now and both Firefox and Chrome support it.
But, the only companies using it are Google and Twitter. I'd like to see web hosting companies offer it as a service

Re:Why aren't people using SPDY, anyway?

[alphred]

I thought that SPDY's only reason for existence is to push more ads on people. Why else would anyone want to use it?

Re:Google only recommends SPDY with SSL/443

[bluefoxlucid]

Why are we discussing SSL? The guy who develops Varnish has said that SSL is a mess, OpenSSL is a confusing and terrifying mess, and SSL is bad because he doesn't understand the code.

https://www.varnish-cache.org/docs/trunk/phk/ssl.html

First, I have yet to see a SSL library where the source code is not a nightmare.

As I am writing this, the varnish source-code tree contains 82.595 lines of .c and .h files, including JEmalloc (12.236 lines) and Zlib (12.344 lines).

OpenSSL, as imported into FreeBSD, is 340.722 lines of code, nine times larger than the Varnish source code, 27 times larger than each of Zlib or JEmalloc.

This should give you some indication of how insanely complex the canonical implementation of SSL is.

Second, it is not exactly the best source-code in the world. Even if I have no idea what it does, there are many aspect of it that scares me.

Translation: SSL libraries are big and scary, SSL is big and confusing and I have no idea what the hell it does so it's bad.

Er... huh? Article full of nonsense

[brunes69]

SPDY is encrypted by design. There is no option for middle-men, and frankly, that is the way I like it myself, as i would assume most people. I don't like when devices mess with my traffic.

As for most of the other complaints - given than Google is running SPDY just fine on all of it's servers, and they're basically one of the largest (if not the largest) hosts on the internet, I think they are all strawmen. If it is working for Google then it will work for others.

My experience using SPDY, as a user, is nothing short of spectacular. The performance gains in on Google properties with SPDY are incredible and very noticeable.

Re:Er... huh? Article full of nonsense

[Anonymous Coward]

What if you have an organization that you want to cache data (not look at it). You pay per megabyte in data sent to/from the web. Wouldnt you want caching? Hell, on your box I bet there are no less than 2 50megabyte caches (unless you have tweaked the size or installed other browsers).

Oh and remember all ISPs out there are drooling to put you on usage based browsing... What if you have a family of 4? Wouldnt you want to have them caching like mad? I myself installed a squid proxy. In the past 6 months I have saved downloading nearly 20 gig of data because of the cache. Average perf boost 10-15%.

Local caching is awesome. Its local and 5-100 times faster than the internet...

The idea is cool. But needs to let you cache. In fact they could go as far as to make caching easier and better. If someone can fetch somthing local that is one less file you have to serve up to them and one more you can serve to someone else. Meaning less hardware to buy and more you can pay to someone to make you better services...

SPDY is cool for what it does. But it needs work and needs to involve guys like this one from varnish and squid.

If you think I am full of it with this caching thing. Disable it on your local box. Set your local disk cache to 1 byte and your memory cache to 1 byte. You will feel the pain quickly.

Re:Er... huh? Article full of nonsense

[markjhood2003]

Forgive my ignorance, but does the encrypted nature of SPDY along with no option for middle-men mean that ad blockers would no longer be possible? That is, do browser plug-ins effectively function as middle-men?

Re:Google only recommends SPDY with SSL/443

[Score Whore]

Conspiracy minded folks would think that SPDY is mainly about Google being able to ensure that advertisements are served before the content. Putting it inside of SSL also ensures that any intermediate carriers won't be stripping Google's adverts.

Firefox or chrome

[higuita]

Just use firefox or chrome in XP, problem solved

HTTP needs to be replaced altogether

[Riskable]

The problem all of these HTTP 2.0 proposals are trying to work around is the fact that each resource fetched by the web browser is handled via a separate connection. By combining these elements into a single (compressed) stream you can save a TON of overhead. This is why sites that use nothing but data::URI images load so much faster--even--than sites using the fastest CDNs. These 'solutions' are just workarounds to the crap that is HTTP 1.1.

Of course, the problem with data::URIs is that they can't be cached if the page's content is dynamic. However, the fact that you don't have to open a hundred additional HTTP connections just to load the cached content (have to check if something changed!) more than makes up for the lack of caching.

The real solution here is to just ditch HTTP and replace it with something like SCTP which can keep the connection open to the server and maintain the session in a secure fashion (negating the need for session-tracking cookies, hurray!). Having said that, such a change to the web would completely break the popular, N-servers-behind-a-load-balancer architecture. It would also negate the need for CDNs (for the most part)... Which is probably why many of the big-name vendors are proposing solutions that maintain the status quo.

Re:HTTP needs to be replaced altogether

[Carewolf]

What overhead, where? You are confusing several issues. One of the reason SPDY sucks is because it still uses TCP like HTTP does. Using HTTP over SCTP would be a great improvement.

The problem with not using TCP though is that you no longer get the well-supported encryption from TLS for free anymore.

Re:HTTP needs to be replaced altogether

[DamonHD]

CDNs will still exist to be (a) high-bandwidth and (b) low-latency close-to-the-user commodity servers of large data volumes.

A change of protocol won't eliminate the limitation of light speed and long-distance comms networks.

Rgds

Damon

Re:Google only recommends SPDY with SSL/443

[Short Circuit]

Translation: SSL libraries are big and scary, SSL is big and confusing and I have no idea what the hell it does so it's bad.

Actually, the better argument I've heard is that it OpenSSL is very poorly documented. And I've heard this complaint from numerous people...to the point where some even started looking into fresh implementations.

So I'm getting a lot of flack for mentioning XML..

[scorp1us]

But really any format that can express structured data is endorsed by me. I do not have a problem with JSON, in fact it is my 2nd favorite. My first favorite is Python's style, which is very, very close to JSON. But JSON has the advantage that web people already know it.

Please don't get bogged down with XML, I wrote XML into my post because despite what you all think, it's not that bad to parse, provided that you use a stream-reader style rather than SAX or DOM. The other reason why I wrote XML is because it does not pre-suppose any kind of scripting engine, so people would not be tempted to use code which would require a JavaScript interpreter, which would end up being a really bad idea.

XML, JSON, Python can all express structured data. They are all equally valid and anything expressed in one can be converted between them all.

Re:Google only recommends SPDY with SSL/443

[LordLimecat]

I have heard the complaint from numerous folks that SSL libraries really are a mess, which is why periodically we get nasty vulnerabilities in them; supposedly, auditing the code is an exercise in futility.

Re:Google only recommends SPDY with SSL/443

[Anonymous Coward]

Conspiracy minded folks would think that SPDY is mainly about Google being able to ensure that advertisements are served before the content. Putting it inside of SSL also ensures that any intermediate carriers won't be stripping Google's adverts.

It also improves user's privacy by preventing personal content from being read by ISPs, proxies, and other men-in-the-middle. If any other web site turned on SSL, we would thank them for choosing to improve user's privacy. But this is Google, so it must be a bad thing.

Google turned on SSL for search a month before they launched personalized search, where the search results can include things only the logged-in user has permission to see (if the user logs in and enables it). If they had not enabled SSL, people would (rightly) be upset that any man in the middle could see photos, documents, and G+ posts shared only with you.

If you punish companies for doing the right thing, expect them to stop. Every company has people for and against any idea. When you punish good behavior, the people who fight for it will not win the argument next time.

XSLT is Turing complete

[tepples]

half of the purpose of a schema -- being a human-readable documentation of the data format

That purpose can be achieved with English.

Schema validation is a very clear example of a situation where it's not good to have a Turing-complete language.

If you specifically don't want something Turing complete when processing XML, then why do XML fans use XSLT despite its being Turing complete?

Re:XSLT is Turing complete

[FrangoAssado]

half of the purpose of a schema -- being a human-readable documentation of the data format

That purpose can be achieved with English.

Sure, but then you have to write the schema AND document it. This can (and does) lead to documentation being out of sync with the code.

If you specifically don't want something Turing complete when processing XML, then why do XML fans use XSLT despite its being Turing complete?

XSTL is a completely different story; it's used to transform XML, not to validate it (which is what XML Schema does). For that, having the flexibility of a Turing-complete language is a good thing (that said, XSLT is still a pain in the ass to use, regardless of being Turing-complete).

Re:XSLT is Turing complete

[ultranova]

half of the purpose of a schema -- being a human-readable documentation of the data format

That purpose can be achieved with English.

I have never once seen documentation written in English that didn't leave something important unclear.

Re:XSLT is Turing complete

[tepples]

Likewise, I've seen XML Schemas that don't completely specify all valid values for a given element. And you still need to consider that XML is much bigger on the wire than JSON. Besides, how does XML's distinction between an "attribute" and a "child text node" map onto the built-in data structures of a programming language better than JSON maps to Java Lists and Maps (or Python lists and dicts, or Perl arrays and associative arrays, or PHP arrays and arrays containing noninteger keys)?

Re:XSLT is Turing complete

[TheGratefulNet]

I have never once seen documentation written in English that didn't leave something important unclear.

so... hindi or russian might be better, you think?

how about german? except that the text size goes 30% larger due to the words being a mil^Wkilometer long.

Google broken? Switch to Bing.

[tepples]

the user will use a browser which is supported. Imagine google only working with sni.

What is the sound of millions of users abandoning Google? "Bing."

Good slide show

[jbolden]

For those who do read the article and didn't understand what the debate was about. Here is a good slide show from google about the advantages of SPDY. Which also explicate the issues in "HTTP routers" in the article: http://www.slideshare.net/bjarlestam/spdy-11723049

Code out of sync with code too

[tepples]

but then you have to write the schema AND document it. This can (and does) lead to documentation being out of sync with the code.

It's not much different from a C# implementation of a mobile application for Windows Phone 7 falling out of sync with the Objective-C implementation of the same application for iOS. Or what am I missing?

Re:Code out of sync with code too

[FrangoAssado]

Nothing, but wouldn't it be great if there was a way to use the same code in both places? XML Schema and the JSON schema proposal I linked before work like that -- a schema is used to validate documents and is at the same time readable as documentation for the document format.

Who has a good VPS for $10/mo or less?

[tepples]

Within a year, most end-users (in the US) will have access to IPv6 from their ISP. Within two years, most end-users will have replaced their non-IPv6 CPEs with ones which support IPv6.

So in other words, IPv6 from the backbone to a home PC's 802.11g radio will be deployed around the time the last mainstream non-SNI PC operating system is scheduled to die anyway.

Me, I'd probably drop support for XP, and let the end-user click through a cert warning if that's what they're inclined to do.

So how would you explain to the users that a blog, forum, or wiki is supposed to raise a serious certificate error after the user is logged in, and that HTTPS with such a serious error is safer for the user than an HTTP connection that can be Firesheeped?

How much more per month are we talking about for a dedicated IP, anyway?

The difference between $5 per month name-based shared hosting, which may put a thousand or more domains on one IPv4 address, and a VPS. You mention a $5 to $7 per month VPS plan; which provider do you recommend?

Seems cheap to me, especially compared to what joe already spent to get a valid SSL cert.

Personal use SSL certificates have been free of charge from StartCom for some time now.

As far as Android...a number of websites are pushing their users to use simple apps instead of the Android browser.

This is true of major web sites like Facebook, eBay, Amazon, and the like, where only one company hosts a particular web application code base. But a lot of smaller web sites run open source web applications, customized with plug-in modules, on top of interchangeable LAMP servers. Is there a standard WordPress app, a standard phpBB 3 app, or a standard MediaWiki app? (I'd Google it, but I'm composing this post offline.) Or must each web site operator duplicate effort in developing an Android app from scratch in parallel with the web site and then walking the users through turning on Unknown sources?

Re:Who has a good VPS for $10/mo or less?

[Short Circuit]

So in other words, IPv6 from the backbone to a home PC's 802.11g radio will be deployed around the time the last mainstream non-SNI PC operating system is scheduled to die anyway [microsoft.com].

Pretty much.

So how would you explain to the users that a blog, forum, or wiki is supposed to raise a serious certificate error after the user is logged in, and that HTTPS with such a serious error is safer for the user than an HTTP connection that can be Firesheeped?

Ask the gentoo guys behind bugs.gentoo.org, who use a CA whose cert isn't generally shipped, or anyone who's using a self-signed cert. I'm not here to get into an argument of over the weights, values and concerns of various degrees of encryption and authentication. For some, it's enough that passive sniffing isn't feasible. For some, that isn't enough, and you need to authenticate the server identity.

Don't ask me to make grand sweeping statements of 'X is enough security', because security is a case-by-case thing. Heck, I note that even Slashdot isn't defaulting to SSL.

The difference between $5 per month name-based shared hosting, which may put a thousand or more domains on one IPv4 address, and a VPS. You mention a $5 to $7 per month VPS plan; which provider do you recommend?

I use prgmr.com. I wouldn't put a full LAMP server on a $7/mo plan; the low-end plans wouldn't really be up to it. But, again, I could easily imagine paying that just so you can drop a squid proxy server on it listening on port 80. Have your domain point to that. Have squid serve as an accelerator proxy, pointing to your shared hosting provider. Squid can wrap your clients' connections with your SSL cert so they can't be firesheep'd on their local wireless or by their local malicious network. Granted, the connection between squid and your shared hosting provider is unencrypted, but the people on that route are far less likely to care. (so long as your VPS and shared hosting provider are in the same country).

Personal use SSL certificates have been free of charge from StartCom for some time now.

StartCom's free certs are only good for a year. You're far better spending off a dollar or two more per month than spending time every year coping with cert rollover headaches. If you can't afford that (after spending $7-10/yr for a domain), I have to wonder why you aren't using a wiki, forum or blog farm that handles these things centrally, and for free.

Is there a standard WordPress app, a standard phpBB 3 app, or a standard MediaWiki app?

There's a Wordpress app. I don't know if a MediaWiki app has cropped up, but I'd been considering writing one as an interface to my own site. I don't know if anyone's written a phpBB 3 app, but I can imagine some real benefits to it. (Imagine having your phone use the normal notification channel to inform you of PMs or replies.)

The market is in a crunch right now, with security concerns and IPv4 address depletion. It's not a pretty situation, and something has to give. Before anything else, that's going to be the IE-on-WinXP market. (IPv6 doesn't even solve the IE-on-WinXP issue, since you need to explicitly enable experimental IPv6 support to get it on WinXP)

According to Google Analytics, my site had 126,947 visits over the last month, and only 5,480 of those were from IE-on-WinXP. That's 4.3% of my traffic. I'd stop giving one whit once that's down to about IE-on-XP once it's down to about 5%, so IE-on-XP is no longer something I need to care about. Heck, I had 22,387 visits from WinXP during the same period, which tells me only one in four WinXP users are still using IE when they visit my site.

IE-on-XP is not a demographic most people need to be reaching for. And, really, if you need TLS, and you need a non-SNI circumstance, and you can't afford another $5/mo (hec

Re:Who has a good VPS for $10/mo or less?

[tepples]

Heck, I note that even Slashdot isn't defaulting to SSL.

SSL is considered a subscriber perk.

I have to wonder why you aren't using a wiki, forum or blog farm that handles these things centrally, and for free.

For one thing, what sort of anti-spam mods and specialized markup mods do MediaWiki and phpBB farms offer? For another thing, it might be a custom web application, other than a popular blog, forum, or wiki, that still needs user accounts. Such an application might form part of a job seeker's portfolio to present to prospective employers who "don’t interview anyone who hasn’t accomplished anything". And if you do user accounts without TLS, you're vulnerable to Firesheep.

And, really, if you need TLS, and you need a non-SNI circumstance

Most shared web hosts that I've looked at don't even offer SNI hosting because they cater to the IE-on-XP demographic.

Re:Who has a good VPS for $10/mo or less?

[Short Circuit]

SSL is considered a subscriber perk.

Ah. I thought I still had subscriber credit. I got one of those 'as thanks for...you can now use Slashdot without ads' emails. Only other time I'd seen that kind of behavior was when I was a subscriber.

For one thing, what sort of anti-spam mods and specialized markup mods do MediaWiki and phpBB farms offer?

Beyond captchas? Very probably things like mod_security, firewall rules blocking bad netblocks from accessing the server. (Doing this was the single most-effective anti-spam mechanism I ever saw.) Using DNSRBLs for realtime tracking of bad source IPs.

For another thing, it might be a custom web application, other than a popular blog, forum, or wiki, that still needs user accounts. Such an application might form part of a job seeker's portfolio to present to prospective employers who "don’t interview anyone who hasn’t accomplished anything" [techcrunch.com].

If you're building a site as part of an operating portfolio with a user base, you can certainly afford an extra IP if you need it. Right now, it doesn't cost very much. If you're merely showcasing a web application, you don't need SSL. If the potential employer is going to ding you for being vulnerable to Firesheep on a site where it doesn't matter, either you're applying for a security-related job, or the guy doing the analysis is a pedantic dick.

And if you do user accounts without TLS, you're vulnerable to Firesheep.

I've never argued otherwise. That said, there are ways to cope with things like Firesheep. Such as tying operating profiles to browser fingerprints. (There's a lot more identifying information in each HTTP request than just your User-Agent string.)

Most shared web hosts that I've looked at don't even offer SNI hosting because they cater to the IE-on-XP demographic.

Then either educate them, use a different provider, or school them by running a shared web host that does offer both SNI and IPv6, and advertise like crazy on Slashdot and Reddit.

Re:Who has a good VPS for $10/mo or less?

[tepples]

Ah. I thought I still had subscriber credit. I got one of those 'as thanks for...you can now use Slashdot without ads' emails.

I get "Disable Ads" too. Perhaps it comes if someone subscribed in the past and then consistently keeps his account's karma Excellent for months, or possibly if someone has configured his browser's Flash Player in click-to-play mode.

Beyond captchas?

After trying for months to keep ahead of spam using a regex extension called AbuseFilter, I ended up realizing that Google's ReCAPTCHA was broken. I switched my MediaWiki to QuestyCaptcha. Each of about a half dozen questions about classic literature links to a Wikipedia article that contains the answer. Successful spammer registrations dropped to zero. Someone using a wiki farm wouldn't have this sort of story to tell to an interviewer.

If you're merely showcasing a web application, you don't need SSL.

In other words, the "warn" method.

Re:Who has a good VPS for $10/mo or less?

[Short Circuit]

After trying for months to keep ahead of spam using a regex extension called AbuseFilter, I ended up realizing that Google's ReCAPTCHA was broken.

I'm still on top of SPAM, but mostly by requiring email confirmation, and by having three or four people who watch the RC feed, block bad users and delete bad content.

I switched my MediaWiki to QuestyCaptcha. Each of about a half dozen questions about classic literature links to a Wikipedia article that contains the answer.

I'll have to check out QuestyCaptcha, but I've got a lot of non-English users. Thanks for the tip!

Successful spammer registrations dropped to zero. Someone using a wiki farm wouldn't have this sort of story to tell to an interviewer.

Honestly, the story of managing load spikes and such in a VPS environment is a far, far more interesting story to tell than anti-spam techniques. Believe me, I've walked the entire path.

In other words, the "warn" method [pineight.com].

Sure.

Re:Who has a good VPS for $10/mo or less?

[zippthorne]

I think it probably has something to do with number of posts, moderations, and karma. I've never been a subscriber, but I get the "browse without ads" option all the time. Ironically, it's more noticeable than the ads (which I rarely bother to turn off).

Now, if it would give me an option to make resizing the window work well (other than tricking it into thinking i'm using a mobile browser), I'd be all over that....

Imagine XP remotely owned in minutes

[tepples]

After April 2014, Microsoft will refuse to supply security updates for Windows XP. Security holes will be discovered, documented, and exploited to the point where connecting an XP machine to the Internet is an invitation to get owned. "If you run XP, you will be hacked." How is that not enough to discourage people from continuing to use XP?

Re:Imagine XP remotely owned in minutes

[shutdown -p now]

My point was that Microsoft is already actively discouraging people from continuing to use XP, to the point that it doesn't make sense to talk about "21 months between now and when Microsoft agrees to let XP die". Microsoft has already agreed to let XP die and is in the process of burying it.

Re:Google only recommends SPDY with SSL/443

[ThatsMyNick]

Putting it inside of SSL also ensures that any intermediate carriers won't be stripping Google's adverts.

Why is that a bad thing? I dont think any intermediary is currently stripping of google ads, and I would rather strip them myself if I had to, rather than depend on any intermediary. Host file list will still work, browser side stripping will continue to work too. I seriously do not see the downside for this.

Re:Er... huh? Article suddenly makes sense...

[lpq]

Ahh... so google properties have converted to this ..

I wondered why my browser turns to crap and hangs on google so often.

That's assume the sites work at all -- so far, google groups has gone completely dark for me... nothing comes up but a input line asking for
groups... but nothing will come up... all javascript enabled, and nothing blocked, yet it doesn't work anymore...

You might look at your assumptions about how well it works...

Lemme guess your browser -- 'Chrome'?

The real reason why the web is slow ...

[Lazy Jones]

Is crap like this (to watch a stupid badger video on forbes.com, you have to load [i.e. trial & error with NoScript] JavaScript from around 25 external websites - pure idiocy). Better implement a feedback mechanism inside browsers that lets web developers who do these things know their website is a slow pile of turd and forget about the useless SPDY that totally misses the point.