FYI: SPDY trial on nightly

[Patrick McManus]

It's time to take SPDY validation to the broader all-nightly audience.
To this point it has been an opt-in preference. Operation is now
generally reported to be stable.

After discussing with the necko team, it is my intention on Tuesday to
turn the spdy pref to be default on. Let me know if that's a problem for
you or your team.

If a few issue reports roll in over the next week I'll disable it at the
end of the week while we investigate those reports and decide how to
proceed. If nothing comes up we'll leave it on, and of course if it
badly destablizes things it will be turned off like any other trunk
feature, to come back another day :)

This note is basically meant to flag that something about your
gmail/gdocs/g+/encrypted-search handling is about to change. If you see
something amiss then send me mail or cc me in bugzilla as apropos.

Thanks!
-Patrick

[Mike Hanson]

Patrick, how do we find out whether SPDY is being used for a particular site? Is there anything in the log or the site identity block that we can look at? Also, is there any way to see whether hostname coalescing has occured for a given connection?

Thanks,
m

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Chris Peterson]

> This note is basically meant to flag that something about your
> gmail/gdocs/g+/encrypted-search handling is about to change. If you
> see something amiss then send me mail or cc me in bugzilla as apropos.

Is there a list of SPDY sites we should focus our testing on? Do all
Google properties support SPDY (if specifying https)?

Also, I like mhanson's suggestion to add SPDY info in the site identify
block.


cp

[Patrick McManus]

On Mon, 2012-02-06 at 09:49 -0800, Mike Hanson wrote:
> Patrick, how do we find out whether SPDY is being used for a particular site?

Hi Mike,

The primary mechanism is via the web console - check the HTTP response
headers and an artificial x-firefox-spdy has been injected if it was
gatewayed through the internal spdy code. (This is a response header in
the browser, so that never hits the network).

anything else that sees headers will also work: liveHTTPHeaders,
firebug, etc..

> Is there anything in the log or the site identity block that we can look at?

There is a ton of related NSPR logging, but I don't consider that a
first tier mechanism.

> Also, is there any way to see whether hostname coalescing has occured for a given connection?

Outside of the NSPR logging there is really no insight into tcp
management of any kind - including things like persistent connection
reuse or HTTP version level (1.1 vs 1.0 vs spdy). I would favor some
kind of information in a deep UI, but from the top level this should all
be transparent stuff.

-Patrick

[Patrick McManus]

On Mon, 2012-02-06 at 10:13 -0800, Chris Peterson wrote:
> > This note is basically meant to flag that something about your
> > gmail/gdocs/g+/encrypted-search handling is about to change. If you
> > see something amiss then send me mail or cc me in bugzilla as apropos.
>
> Is there a list of SPDY sites we should focus our testing on? Do all
> Google properties support SPDY (if specifying https)?
>

Hi Chris,

I believe they all do. beyond google, https://spdy-twitlog.indutny.com/
is a node.js spdy instance that can be used to confirm your browser is
up to the spdy task.

A couple google services tend to redirect you away from https (youtube
iirc), but for the most part they all do spdy over https.

Notably, if you are logged into a google account you will be redirected
from http:// to https:// (and thus potentially spdy) when you go to the
search page which is something mostly great they've been doing for a few
months.

An unpleasant twist, unrelated to spdy, on that means that the search
dialog in firefox does this redirect too - so you take a extra round
trip for the redirect AND your search is sent in plaintext first, which
is clearly suboptimal. (633773 has the backstory on why we don't just
send it in https to start with, and that bug is a better place for that
line of discussion than this spdy thread imo.)

-Patrick

[Henri Sivonen]

On Mon, Feb 6, 2012 at 8:23 PM, Patrick McManus <mcm...@ducksong.com> wrote:
> The primary mechanism is via the web console - check the HTTP response
> headers and an artificial x-firefox-spdy has been injected if it was
> gatewayed through the internal spdy code.

Is this header visible to XHR? If it is, will it be removed before
release so that Web content won't start depending on it?

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Patrick McManus]

On Mon, 2012-02-06 at 21:59 +0200, Henri Sivonen wrote:
> On Mon, Feb 6, 2012 at 8:23 PM, Patrick McManus <mcm...@ducksong.com> wrote:
> > The primary mechanism is via the web console - check the HTTP response
> > headers and an artificial x-firefox-spdy has been injected if it was
> > gatewayed through the internal spdy code.
>
> Is this header visible to XHR? If it is, will it be removed before
> release so that Web content won't start depending on it?
>

Hi Henri,

Yes its visible like other normal headers. As its pretty clearly vendor
specific, I wasn't planning on removing it.

But if you feel strongly I think you should file a bug and let the
product and dev tools teams decide what behavior they want. cc me too,
please.

-Patrick