

SPDY Review by Opera Software - jacobr
http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0498

======
forgotusername
Another dirty little secret is that WebSocket does not (yet) work over SPDY,
despite the fact both protocols essentially originated in house at the same
company.

Both are effectively hacks on existing well established protocols, but both
affecting different layers. With WebSocket, you cannot use your tried and
tested HTTP parser. With SPDY, you cannot use your tried and tested SSL
implementation. With a little bit of foresight, implementation of both might
have involved use of only SSL Next Protocol Negotation (SPDY's approach) and a
completely separate, orthogonal SPDY/WebSocket parser. This would also remove
some of the more "innovative" features of WebSocket (Sec-WebSocket-Key and
that magical fixed UUID).

This is a testament to how heavily rushed both protocols were, and the kind of
thing that could be avoided with a more strongly community lead process, which
was missing at least in the early stages of WebSocket. I have no idea what it
was like for SPDY, but given that the "innovative" header compression feature
somehow survived, I'm guessing not good.

~~~
fibertbh
"Rushed" is the wrong opinion to have about it.

What's impressive is that at _no other company_ you could wake up one morning
and say, "HTTP is slow, so let's change that." Google, amazingly, can do stuff
like that, and I'd rather them ship early than not ship at all.

(Well I guess Microsoft could have done it but they would have screwed it up
like every other net technology they introduce and then we'd have two
internets or something worse.)

~~~
gecko
I'm not sure it's fair to say that Microsoft has "screwed up" every technology
they've had a hand in. Ajax, notably, is a Microsoft invention. What I do
think is a fair statement is that Microsoft has historically been slavishly
backwards-compatible _even with obvious design mistakes and implementation
artifacts_ , whereas the other two 800-pound gorillas (Google and Apple) have
a mantra of never keeping legacy tech around when it can safely be replaced.
The latter results in cleaner technologies; the former results in longer-
living technologies. As a programmer, I prefer the Google/Apple take, but it's
worth noting that Microsoft's variant has a clear advantage for the user in at
least the short-to-medium term.

~~~
huggyface
_Ajax, notably, is a Microsoft invention._

To put that into proper context, XmlHttpRequest was a hack by a _single
person_ at Microsoft -- with zero input or coordination or working groups or
long term planning -- on the MSXML team to do a favour to the Outlook team.
Further it could only happen because of ActiveX, and paralleled various other
light request tools that existed at the time.

XmlHttpRequest is a great demonstration of a hacker getting a solution out
there.

EDIT: Downvotes? I am intimately aware of how XmlHttpRequest came into
existence, having been closely involved with its birth, so if someone has some
correction to add, please add it. But in no universe does XmlHttpRequest
vindicate Microsoft on moving web standards along. Their contribution was
unintentional and largely accidental.

~~~
specialist
I wouldn't down-vote your comment.

During my interview with that team, one of the kids proudly took credit for
the span tag. A weekend hack. Committed the code and shipped it. No review.
SOP.

Being more standards-minded at the time, I wanted to throttle the kid.

With the benefit of hindsight, I see that all the jitter and experimentation
was pretty much ideal. If a feature proves useful, other browsers may adopt
it, and it may become a de facto standard.

~~~
cheatercheater
And if it didn't, it still stayed in and caused one of a thousand
incompatibilities used by masses of clueless people around the world.

------
majke
> While the concerns is valid, flow control looks like overkill to something
> where a per-channel pause control frame could do the same job with less
> implementation and protocol overhead.

Coming from messaging world I can say: nope. "Pause" frames are a very, very
bad idea and lead to more problems than they solve. Windowing is much better
engineering choice.

> Also note that TCP provides the URG channel for exception messaging.

Which doesn't work.

> 2.6. Push ... The client has the option to read and discard this
> information, but that may be a costly waste of bandwidth.

It's worth noting that caching and Push don't play together.

~~~
dboat
All your assertions are unsubstantiated. I'm not saying they're wrong, I'm
just pointing out that you haven't explained any of your claims. You needn't
go to any great length to cite sources, but a sentence or two of facts or
explanation to match each assertion would make your post more useful to read.

------
dkhenry
The biggest takeaway I get form this is that Opera has done this before but
never shared it with the outside world. At a minimum we know that the kind of
speed up SDPY proposes is possible and apparently used in production systems.

~~~
jerf
It is well known that Opera has done a lot of work in this area:
<http://en.wikipedia.org/wiki/Opera_Mini#Functionality>

Of all the parties Google should listen to for SPDY feedback, Opera is
probably the top of the list. It looks like Opera took it quite seriously and
shared a lot of good work with us all, and I thank them for it. I'd say their
point about the asynchronous headers is one that requires serious addressing
ASAP. For one example, is it valid to push down a header redeclaring the
encoding of the response at the very end? What would that even mean? It's a
good point.

~~~
mdwelsh
There's a big difference between having a closed, proprietary protocol and
releasing something as open source with a public spec.

~~~
jerf
I'm having a lot of trouble with people imputing argument to me I'm not making
this week. My point is that this is a known thing that they have this
experience, not that Opera Mini solves anything else, and that their
experience is highly relevant.

~~~
mdwelsh
Sorry for not being clear. I completely agree that Opera's experience is
relevant and useful. They have done some great work on optimizing mobile web
performance and it would be fantastic to draw on that expertise to make open
standards which everyone can benefit from. However, don't forget that SPDY and
related technologies create a problem for Opera, which is based on a closed
protocol and ecosystem. Personally, I believe in an open web based on open
technologies which can be implemented by anyone. Without releasing code or a
spec, it's easy to take a position that your approach is better - since nobody
can scrutinize you to prove otherwise.

~~~
jerf
Where do you see them claim their approach is better? Preferably with quotes.

It seems likely but I can't prove that behind a couple of statements like "As
defined the feature is not powerful enough to push non-request related content
(such as new RSS items)" is the fact that their approach does do it (and
possibly had to add it on later only after they discovered it was a problem),
but the document is very carefully written strictly as an examination of SPDY,
with no braggadocio I can see at all or any trace of marketing beyond the
initial statement of "Hey, we've done some stuff and here's some observations
we are in a position to make".

(Again, my compliments to the chefs.)

------
rfugger
Seems like a lot of the issues they bring up would be addressed by using SCTP
as a transport instead of TCP. Why aren't we moving in that direction?

~~~
bradleyjg
There are billions of dollars worth of ASICs in the wild designed to
accelerate processing TCP.

~~~
cheatercheater
There were billions of dollars worth of silicon in the wild designed to
execute PDP-11 microcode.

------
j_s
> 2.5. Asynchronous headers ... While this is already possible to do with
> chunked encoding trailer, it is not a feature in popular use.

Can anyone point to a working example of this use of a chunked encoding
trailer? It seems like a solution to the primary problem that came up on the
discussion of HTTP Streaming: <http://news.ycombinator.com/item?id=4042247>

> And if it for instance needs to redirect the user, it can’t change the
> status/headers to a 302/Location if it’s already ...

~~~
cwp
Yeah, I went down this road too. It looks like a good way to handle exceptions
during streaming, but browser support is essentially zero.

~~~
smallblacksun
Does it work in Opera?

~~~
gsnedders
Reinterpreting content? Nope. Opera (and only Opera) does anything with them —
they're available through `XMLHttpRequest`.

------
ricardobeat
They sound defensive. That's probably a good thing.

Can someone explain how Microsoft's S+M proposal differs and how well it would
work in the real world with proxies, firewalls, NAT etc? (I'm being lazy and
haven't read the paper)

~~~
mbelshe
The biggest difference between SPDY and Microsoft's proposal is that
Microsoft's proposal is only theory at this point. The SPDY proposal has
dozens of independent implementations behind it and 3 years of operational
experience.

I'm not trying to dis the proposal; just point out that it is in its infancy.
To jump start it, Microsoft started with SPDY at its core, but changed the
syntax.

------
b7kich
Great read. Thanks for sharing!

------
rbhm
"so lots of heuristics has to be applied"

I would think if I was going to submit something to W3C I'd consider asking
someone to proofread it.

~~~
gecko
It's a 2200-word document written by someone whose native language isn't
English, and there is a single verb that doesn't agree with its subject. Since
that's the only actual complaint you appear to have about the document, I'll
assume you agreed with the very well reasoned, well researched viewpoints
therein. Overall worth reading, I'd say.

~~~
rbhm
still working my way through it, but was certainly put off by a lack of
respect for the language it was written in.

~~~
silvestrov
Opera Software is located in Norway. Let's see how much "respect" you have for
the language if you have to write in Norwegian.

I bet their English is better than yours. You didn't even start the first word
using a capital 'S', so you have a mistake already when writing a single
sentence.

~~~
hoppipolla
Random pedantic fact: Martin, and several of the listed contributers work in
our office in Linköping, Sweden.

