Bug 77349 - Track the NPN protocol version negotiated with the server
Summary: Track the NPN protocol version negotiated with the server
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: raman tenneti
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-30 11:57 PST by raman tenneti
Modified: 2012-02-18 22:26 PST (History)
4 users (show)

See Also:


Attachments
Patch (6.08 KB, patch)
2012-01-30 16:30 PST, raman tenneti
no flags Details | Formatted Diff | Diff
patch to add extra data to WebURLResponse (7.58 KB, patch)
2012-02-17 11:29 PST, raman tenneti
no flags Details | Formatted Diff | Diff
Patch (9.86 KB, patch)
2012-02-17 18:28 PST, raman tenneti
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description raman tenneti 2012-01-30 11:57:20 PST
This is part of measuring effectiveness of SPDY; Track the protocol version (http/1.1, spdy/2 or spdy/2.1 or ...) which was negotiated with the server using TSL/NPN mechanism. chrome:loadtimes will display the protocol version that is negotiated.
Comment 1 raman tenneti 2012-01-30 16:30:30 PST
Created attachment 124624 [details]
Patch
Comment 2 WebKit Review Bot 2012-01-30 16:34:35 PST
Please wait for approval from fishd@chromium.org before submitting because this patch contains changes to the Chromium public API.
Comment 3 raman tenneti 2012-01-30 16:41:42 PST
Comment on attachment 124624 [details]
Patch

Hi Darin,
  We wanted to add support in chrome:loadtimes to print the NPN protocol that was negotiated (servers could decide which SPDY protocol they would like to use - either SPDY/2 or SPDY/2.1. We would like to log the protocol server and client have negotiated). 

Would appreciate your comments.

thanks
raman
Comment 4 Darin Fisher (:fishd, Google) 2012-01-30 23:38:23 PST
Comment on attachment 124624 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=124624&action=review

> Source/WebKit/chromium/public/platform/WebURLResponse.h:151
> +    WEBKIT_EXPORT WebCString protocolVersion() const;

this field and the NpnNegotiated field don't really belong in webkit.  you are adding
this one here just as plumbing.  the same was true when NpnNegotiated was added.

since then, we have developed a way to attach opaque extra data to a WebURLRequest
(and underlying ResourceRequest).  can you use that instead?

see WebURLRequest::setExtraData.

On the chromium side, look at RenderViewImpl::willSendRequest to see where
setExtraData is called.

it would be great if you could move NpnNegotiated too! :-)
Comment 5 raman tenneti 2012-01-31 09:53:58 PST
> since then, we have developed a way to attach opaque extra data to a
> WebURLRequest (and underlying ResourceRequest).  can you use that instead?

The above is awesome. Will make the above changes and will resubmit it for review.

thanks much,
raman
Comment 6 raman tenneti 2012-02-17 11:29:57 PST
Created attachment 127618 [details]
patch to add extra data to WebURLResponse

Hi Darin,
  I am really sorry for the delay in uploading this change. Would appreciate if you could take a look at this patch.

thanks very much,
raman
Comment 7 raman tenneti 2012-02-17 17:01:07 PST
Comment on attachment 127618 [details]
patch to add extra data to WebURLResponse

Will upload the patch using proper webkit procedure. Deleting this patch. Sorry about that.
Comment 8 raman tenneti 2012-02-17 18:28:11 PST
Created attachment 127683 [details]
Patch
Comment 9 WebKit Review Bot 2012-02-18 22:25:58 PST
Comment on attachment 127683 [details]
Patch

Clearing flags on attachment: 127683

Committed r108184: <http://trac.webkit.org/changeset/108184>
Comment 10 WebKit Review Bot 2012-02-18 22:26:02 PST
All reviewed patches have been landed.  Closing bug.