Lukasa

9 ms·

31.
by Lukasa 11y ago
It is not categorically different. As I said above, green threading has advantages over OS threading, but they behave exactly the same in terms of design patterns and potential bugs. This is what I was getting at when I said "not that
32.
by Lukasa 11y ago
I agree with this entirely. As I said many times before, I like Go and I like its approach to concurrency. All I'm trying to do is to make sure that people who make bold claims about abstracting away blocking code aren't misleadin
33.
by Lukasa 11y ago
Honestly, I think the distinction between M:N threading and straight OS threading is pretty minor. It grants some advantages to the language runtime: it can control the stack size, for example. But in terms of how it affects the development
34.
by Lukasa 11y ago
> The caller can make function "non-blocking" by wrapping the call in a goroutine themselves. Sure, but if they want the return value then either they need to construct the Future-y wrapper I just described or they need to asse
35.
by Lukasa 11y ago
I agree with almost all of your post except this: > With Go it doesn't matter if an operation is blocking or non blocking, that fact can totally be abstracted from the client code. No, it can't, and pretending that it can is mi
36.
by Lukasa 11y ago
There's already lots of this. That's basically what Twisted is, for example.
37.
by Lukasa 11y ago
Why?
38.
by Lukasa 11y ago
Only if the file is served as one large chunk. If sent using Transfer-Encoding: chunked, there is no requirement to provide a Content-Length header, and a HEAD request may not show one. The way Go's built in HTTP libraries work is that
39.
by Lukasa 11y ago
Yeah, so this is an interesting feature because in my experience it doesn't work. [We added one]( https://github.com/kennethreitz/requests/blob/master/CONTRIB... ) for the Requests module a little whi
40.
by Lukasa 11y ago
Oh if only that were possible. However, many people are using older OpenSSLs with no route to upgrading. For example, Ubuntu 14.04 is using OpenSSL 1.0.1 currently, and will not upgrade to any later release of OpenSSL. It's unlikely to
41.
by Lukasa 11y ago
You have to read the follow-up post to get a good description of why this won't work, but let me try. The problem is that most clients currently are not able to build up multiple trust chains. They hand OpenSSL the certificates the rem
42.
by Lukasa 11y ago
Good spot Rob! In the past we (urllib3) have been pretty optimistic about assuming connections are still useful when we hit exceptions, but increasingly that optimism seems to be hurting us. For that reason, I've taken your fix, added
43.
by Lukasa 11y ago
Yes. Remember, signing/encryption do not ensure that you can communicate, only that if you communicate you can do so with integrity, authenticity, and privacy. The same limitation applies here, with the added bonus of this particular
44.
by Lukasa 11y ago
Twitter re-compresses the image, sadly, so that doesn't work. As I said elsewhere, there are other options, like QR codes or high capacity colour barcodes, but those aren't funny.
45.
by Lukasa 11y ago
So you can't do a direct 1-to-1 mapping of pixels to bytes, because Twitter re-compresses the image. You cannot rely on the binary representation of the image to make that work. However, there are plenty of other, less funny, options,
46.
by Lukasa 11y ago
Entirely accurate! The interesting thing about the poor man's OCR is that it works way better than out of the box OCR tools. They're all built around handling arbitrary, often quite noisy input, so their handling of 1s and ls in t
47.
Entweet: Securing Twitter(github.com)
35 points by Lukasa 11y ago|19 comments
48.
by Lukasa 11y ago
> Do these HTTP/2 server implementations downgrade to HTTP0.x/1.x if the client support only an older version? Many do, yes. > Will there be v2-only servers in near future? Yes. > Debugging and implementing older protocol
49.
by Lukasa 11y ago
Sure it does. HTTP/2 streams are bidirectional. The websocket flow can be perfectly emulated in HTTP/2: make a websockety request, get a 200 HTTP response, then both sides keep the stream open and send data through it.
50.
by Lukasa 11y ago
Nope, nghttp2 and h2o have been floating around for a long time now.
51.
by Lukasa 12y ago
Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
52.
by Lukasa 12y ago
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial
53.
by Lukasa 12y ago
Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many
54.
by Lukasa 12y ago
Leaving aside the technical statements about SPDY, the reality of HTTP pipelining is that no-one uses it. According to Wikipedia, Opera is the only major browser that ships with pipelining enabled. Most intermediaries don't support pip
55.
by Lukasa 12y ago
Working well with quic is not a design goal of HTTP/2. However, my understanding is that quic was originally designed to work well with SPDY, and so ought to work well with HTTP/2 as well. There'll definitely be some Googlers
56.
by Lukasa 12y ago
> Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change
57.
by Lukasa 12y ago
I got the impression that Microsoft is backing this because of pressure from large enterprises, which do not want to deploy TLS in their intranets. I don't believe IE will prefer plaintext HTTP/2 to TLS HTTP/2, and it will
58.
by Lukasa 12y ago
There are a few key points here. First, Ilya's slides are out of date. The reference set got removed (it was a complexity nightmare), so there's a bit less efficiency in deltas but a substantially simpler algorithm for header sets
59.
by Lukasa 12y ago
No problem! > Is there a C implementation of it? Currently there's no good standalone version, because we're still at interop stage. Take a look at nghttp2[0], however. They've got a HPACK layer that I believe can be separ
60.
by Lukasa 12y ago
In practice it very nearly does. Only IE plan to support plaintext HTTP/2, all other browsers will only support it over TLS. Opportunistic Encryption is still on the table as well.

More ›