New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Feature

Blocked on:
issue 799935

Sign in to add a comment

Issue 850143: HTTP/2 session reuse does not happen across credentialed and uncredentialed requests

Reported by, Jun 6 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36

Steps to reproduce the problem:
1. Run webpagetest on chrome for url
2. See the waterfall after the test
3. Notice that (around step #15) SSL handshake happens again for domain 

or see the web page test result at

What is the expected behavior?
The domain is part of the TLS certificate for and any calls to it should be trusted after the initial handshake. i.e should happen only once at the beginning.

What went wrong?
around step #15, SSL handshake happens again for domain
The request is for font data

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 67.0.3396.62  Channel: stable
OS Version: 
Flash Version: 

For webpagetest, issue occurs on Android too.

Comment 1 by, Jun 6 2018

Components: Internals>Network>HTTP2
Status: Untriaged (was: Unconfirmed)
Summary: HTTP/2 session reuse not happen across credentialed and uncredentialed requests (was: SSL handshake renegotiating during Web Page Test)
(Yeesh your site connects to a lot of hosts...)

This is about HTTP/2 connection reuse, despite the title. I did my own run of it here, but this time had it capture the NetLog and it does reproduce this.

Specifically this is caused by being uncredentialed and we split credentialed connections from uncredentialed ones.

+rsleevi, I don't know if there is an existing bug to dup this into. This is something we're evaluating, but there's a long path of things to change or sort out before we get there, if we decide to.

Comment 3 by, Jun 6 2018

Uncredentialed meaning sent without cookies and such (CORS anonymous).

I don't know whether other browsers shard that way. Our history here is a little funny.

Comment 4 by, Jun 7 2018

Got it. Would it help if we put the font request on the same origin (

Also, at the risk of digressing a bit but since you mentioned that we connect to a lot of hosts... 
are there any optimizations you can suggest, wrt to hosts, subdomains or number of requests?

Comment 5 by, Jun 7 2018

Blockedon: 799935
Labels: -Type-Bug -Pri-2 OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Mac OS-Windows Pri-3 Type-Feature
Status: Available (was: Untriaged)
So the 'with credentials' aspect is presently spec'ced as - namely, that it requires the font fetch be made with CORS Anonymous mode. "When fetching, user agents must use "Anonymous" mode,"

This triggers a separate socket connection. This is documented in . Changing that is being tracked in

Changing it to be same-origin will not change that behaviour. You could use preconnect to preconnect in anonymous mode.

As David mentioned, we're exploring the possibility of changing that, both in Fetch and implementation, but that's a rather substantial change, and it's blocked on other rather substantial changes, such as Issue 799935.

Tagging this as a P-3/Feature request, since it'll also require the spec change

Comment 6 by, Jun 8 2018

Summary: HTTP/2 session reuse does not happen across credentialed and uncredentialed requests (was: HTTP/2 session reuse not happen across credentialed and uncredentialed requests)

Comment 7 by, Jan 15

Labels: Enterprise-Triaged

Sign in to add a comment