hobohacker

5 ms·

1.
by hobohacker 10y ago
Ex-USDS here. Did 6 months at USDS, still federally employed as a USDS reserve. Just wanted to chime in on "Who in their right mind would go to work for the government, for minimum wage, unless they were already independently wealthy?&
2.
by hobohacker 11y ago
To answer your specific question about why not in TCP, it's not deployable. Here's why: * In order to get multiplexing and other features introduced with HTTP/2, you need to change protocol framing. However, this means that t
3.
by hobohacker 13y ago
Er, I thought I was agreeing with you. What do you think I'm arguing? To be clear, I view these two statements as grounded in the same logic, although perhaps one is more strongly worded than the other: Yours - "So unless someone
4.
by hobohacker 13y ago
I think it's a fair assessment that supporting experimental technologies requires more engineering resources. Everyone has to do the cost/benefit analysis themselves.
5.
by hobohacker 13y ago
Speaking as a Chromium SPDY & HTTP/2 developer, we are very much focused on standardization. SPDY is an experimental protocol meant to drive the standards process, not become a de facto standard itself. Therefore, it's critica
6.
by hobohacker 13y ago
I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2..
7.
by hobohacker 13y ago
Only time will tell. It's all still in progress. Of all the major browser vendors (Firefox, Chromium, IE) present at the Zurich HTTP/2 interim meeting, only Patrick McManus (Firefox) has expressed interest. Notably, he's a co
8.
by hobohacker 13y ago
The specification indeed is about proxying http resources, not https ones. So it's not initially as alarming as some other proposals discussing trusting proxies to intercept SSL connections. For more details, you can refer to https:&#
9.
by hobohacker 13y ago
As Patrick McManus says in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/... : If someone can install a root cert onto your computer then you are already owned - there is no end to the other
10.
by hobohacker 13y ago
Perhaps you should look at the Hacker News comments on that thread: https://news.ycombinator.com/item?id=7249193 . Notably, my comments: https://news.ycombinator.com/item?id=7249560 and https://ne
11.
by hobohacker 13y ago
HTTP/2 does not change the meaning of http:// . That's the opportunistic encryption proposal: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-... . For more information, you can see htt
12.
by hobohacker 13y ago
I guess I should out myself as a Chromium HTTP stack maintainer (since 2009, so this behavior predates me). One might consider me a domain expert here. I participate in IETF HTTPbis for the HTTP/2 work as the primary Chromium represent
13.
by hobohacker 13y ago
I think the author of this blogpost has a few things off: - HTTP2 != httpbis. Both work is being done by the same working group "httpbis". http://datatracker.ietf.org/wg/httpbis/charter/ covers this
14.
by hobohacker 13y ago
That's true, which is why I was careful to say in its original form :) Since the original attack was on cookies (request headers). To my knowledge, no other SPDY server defaults response header compression to off. But yeah, if your app
15.
by hobohacker 13y ago
Let's be clear that the original CRIME attack was against request header secrets. Therefore, disabling response header compression (as nginx defaults to) does not prevent that. SPDY/3.1 request header compression is a client-side
16.
by hobohacker 13y ago
Head of line blocking is when something ahead in the line blocks things behind it. If browsers choose to use connection limits, then that means that things ahead in the line and get to use the connections are blocking things behind in line
17.
by hobohacker 13y ago
To your points about pipelining, there's a reason it doesn't get compared. It's not usable - https://insouciant.org/tech/status-of-http-pipelining-in-chr... Head of line blocking is so well documented th
18.
by hobohacker 13y ago
I'd love to hear what's stopping you from forcing SSL site-wide. Is it cost? If so, what are the specifics if you don't mind sharing? Also, I don't know if you're using different VIPs for load balancing or lack of S
19.
by hobohacker 13y ago
https://code.google.com/p/chromium/issues/detail?id=22423 discusses some of the issues with using SRV records in browsers. SRV records could help clients discover server HTTP/2 support, but it does not m
20.
by hobohacker 13y ago
I'm not going to argue whether or not other libraries/protocols (e.g. your example of protobufs) may provide higher value. I was simply questioning your assertion "SPDY has no benefit for mobile APIs." That said, I've got some comments on y
21.
by hobohacker 13y ago
http://www.chromium.org/spdy/spdy-whitepaper has data on improvements in lab tests. http://googlecode.blogspot.com/2012/01/making-web-speedier-a... has a blurb where Google announces that they've made search (already highly optimized) f
22.
by hobohacker 13y ago
Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head: * SPDY Multiplexing is superior to HTTP pipelining. Pipelining requires in-order responses, which leads to head of line blocking
23.
by hobohacker 13y ago
Can you clarify this statement? Perhaps there's missing context, but as it reads, it seems like a false statement. When I look at chrome://view-http-cache/, I see a bunch of https:// resources for google.com (which are served over SPDY).
24.
by hobohacker 14y ago
It depends on what you mean by atomic. Please refer to http://www.chromium.org/developers/design-documents/indexedd... where Chromium devs state: """ LocalStorage is inherently racy or a parallelism disaster, depending on whether or not y
25.
by hobohacker 14y ago
The primary caveat with this approach is race conditions due to lack of locking. Note the "Issues" section in http://www.w3.org/TR/webstorage/ which says: """ The use of the storage mutex to avoid race conditions is currently considered b
26.
by hobohacker 14y ago
No, we have never had an infinite cache. What is more likely is that your friend may have encountered a bug. If he has information on this issue, please file a bug at crbug.com/new and I will be happy to triage it.
27.
by hobohacker 14y ago
I am said Chromium developer. Let me respond to this comment from the article: """ This is not the case for Chrome: the browser keeps all the cached information indefinitely; perhaps this is driven by some hypothetical assumptions about bro
28.
by hobohacker 14y ago
Sorry, I'm a Chromium dev, and in particular I'm the net maintainer who authored the majority of the current connection management code you are discussing. Our results are not public. The web compat concerns are with more exotic, enterprise
29.
by hobohacker 14y ago
Chromium builds predictive models which are stored client-side. They are not uploaded to a third party server, like Google.
30.
by hobohacker 14y ago
We've considered this before, and the performance gains do not appear worthwhile (we've run much more extensive tests than you have on top websites to evaluate potential gains), it has extra complexity, it is more of a Hampering Eyeballs ap

More ›