31–40 of 60 posts
Earlier quoted context omitted.
It's quite a gift for embedded systems. It's very convenient to have a self-contained solution for a web interface, rather than drag an interpreter and a web server on an already crowded rootfs. Plus, you can get the benefit of static analysis and the like, which is extra useful on such systems.
I believe there are relatively many AOT-compiled-to-native-code languages other than C.
Why the ISC license? The site just says "Kore is licensed under the ISC license allowing it to be used in both free and commercial products." but don't Apache 2, BSD, and MIT all satisfy this as well. IANAL, but here's a quick summary of ISC vs MIT: http://www.tldrlegal.com/compare?a=MIT+License&b=ISC+License
> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit)
> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit)
I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't g…
> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit)
SPDY isn't necessarily insecure. Disabling header compression, for instance, works around the CRIME vulnerability.
Earlier quoted context omitted.
SPDY isn't necessarily insecure. Disabling header compression, for instance, works around the CRIME vulnerability.
Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
Why the ISC license? The site just says "Kore is licensed under the ISC license allowing it to be used in both free and commercial products." but don't Apache 2, BSD, and MIT all satisfy this as well. IANAL, but here's a quick summary of ISC vs MIT: http://www.tldrlegal.com/compare?a=MIT+License&b=ISC+License
Even WTFPLv2 is not good.
Earlier quoted context omitted.
Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
You can use a compression level of 0. That is, pass through.
Having known vulnerabilities baked into a standard with "weird looking" mitigation strategies is really poor choice IMO.
That said, I do see your point. There are also other edgecases, like serving statics on a seperate, uncookied domain that benefit greatly from SPDY in the here and now.
Earlier quoted context omitted.
I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't g…
Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.
I guess SPDY fans' marketing of this "feature" would be more convincing if I could see a demonstration.
I just don't see any noticeable delays when using pipelining.
What strikes me as peculiar about the interest in SPDY is that I never saw any interest in pipelining before SPDY. And I really doubt it was because of potential head of line blocking or lack of header compression. I think users just were not clued in about pipelining.
The speed up between not using pipelining and using it is, IME, enormous. 1 connection for 100 files versus 100 connections for 100 files. It is a huge efficiency gain.
Yet most users have never even heard of HTTP pipelining, or never tried it. If they really wanted such a big speed up, why wouldn't they use pipelining, or at least try it? Why wouldn't they demand that browsers implement it and turn it on by default?
Users are being encouraged to jump right into SPDY, a very recent and relatively untested internal project (e.g. see the CRIME incident) of one company, most users, if not all, having never previously experimented with even basic pipelining, which has been around since the 1999 HTTP/1.1 spec and has support via keep alives in almost all web servers.
Noticeable speed gains would be seen if www pages were not so burdened with links to resources on external hosts. That's what's really slowing things down, as browsers make dozens of connections just to load a single page with little content. The speed gains from cutting out all that third party host cruft would make any speed gains from avoiding theoretical potential head of line blocking during pipelining seem miniscule and hardly worth all the effort.
If you want to see how much pipelining speeds up getting many files from the same host, you do not need SPDY to do that. Web servers already have the support you need to do HTTP/1.1 pipelining. (Though on rare occasions site admins have keep-alives disabled, like HN for example. In effect these admins are saying, "Sorry, no pipelining for you.")
Earlier quoted context omitted.
I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't g…
Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.