Same here. My (crusty) default Windows Chromium profile is hitting this. LMK if you want a copy. In the mean time, I'll use --user-data-dir= to make it actually work.

I have been able to reproduce it, even after blowing up my profile directory, but... not now, for some reason.

I have been able to reproduce it too.

rch, ckrasic: A long shot, but any chance this could be related to  Issue 613079 ? The fact that we're having issues in header code, and the CL touches headers (albiet with SPDY/HTTP/2) make me wonder if perhaps some invariant has changed.

sleevi: I don't think so. that issue was caused by a SPDY change which landed just yesterday (or the day before?) and is being reverted now. But this issue started before then.

It started for me when I pulled on May 12 IIRC. So somewhere May 11ish probably?

 Issue 611639  has been merged into this issue.

At least one Cronet embedder is hitting this. Internal bug: b/28841175

This is occurring in 52.0.2739.0.

Misha pointed out this is most likely due to https://codereview.chromium.org/1965833002/, where we stopped adding an implicit "vary: cookie" header to responses.  I'm not sure what the implications of the DCHECK are, so marking it a release block stable until we figure them out - if it's not a huge deal to ship without a fix, can just remove the label.

 Issue 613602  has been merged into this issue.

I expect this DCHECK to trigger whenever using a cached redirect from before build 392956, in which the redirect did NOT have a Vary header. The confusion is that we have response headers that were stored with a Vary MD5, yet the response headers don't contain Vary. Because we are no longer adding "Vary: cookie"

Since we are intentionally changing how vary data works, we should probably remove the DCHECK. At least if the response is a redirect. But that isn't ideal, it's returning "false", and so an unconditional request will be sent. We can do better: we should be able to use these responses.

Idea 1: If the response has Vary data, but no Vary header, we just use the response, assuming that the Vary data was just a cookie.

Idea 2: If the response has Vary data, but no Vary header, we use the response if the Vary data matches make-believe Vary data containing only our cookie.

Not a big fan of keeping around any remnant of the Vary-Cookie magic.  Seems like it would just serve to get us into trouble if make a change that results in us running into this problem in the future.

I'd suggest just removing the DCHECK, and maybe bringing it back at some point in the future, if we think we can (Like if we ever get rid of the blockfile cache, and then change the format of the simplecache, completely invalidating all entries, or maybe just after enough time passes).

Sorry for the delay, was OOO.

Here is the CL removing the NOTREACHED(): https://codereview.chromium.org/2000123002/

I think a proper fix would be to replace a HttpVaryData::MatchesRequest() with a HttpVaryData::Compare(), so that the Init is done by the user of HttpVaryData.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ec544a858f4dd2b5b3a0ad0949a1f24f55f10b4

commit 7ec544a858f4dd2b5b3a0ad0949a1f24f55f10b4
Author: gabadie <gabadie@chromium.org>
Date: Mon May 23 14:20:43 2016

Fix a crash in HttpVaryData::MatchesRequests.

 crbug.com/469675  remove an implicit Vary: Cookie for redirected
requests. But some cached redirected requests could still have
HttpVaryData::is_valid_ == true.

Therefore some requests could reach a NOTREACHED() in
HttpVaryData::MatchesRequests() because comparing an HTTP request
vary that have a HttpVaryData::Init() now returning false because
no Vary from the request with a previously cached HttpVaryRequest
that have is_valid_ == true.

BUG= 611575 

Review-Url: https://codereview.chromium.org/2000123002
Cr-Commit-Position: refs/heads/master@{#395317}

[modify] https://crrev.com/7ec544a858f4dd2b5b3a0ad0949a1f24f55f10b4/net/http/http_vary_data.cc

We still need this to be merged into M52.

You can request merges on issues marked as "Fixed".  I believe that's the more common process, actually.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ac453e0ec84fd9f1c87bf06080eca3a586f32bee

commit ac453e0ec84fd9f1c87bf06080eca3a586f32bee
Author: Gavin Peters <gavinp@chromium.org>
Date: Tue May 24 14:25:40 2016

Fix a crash in HttpVaryData::MatchesRequests.

 crbug.com/469675  remove an implicit Vary: Cookie for redirected
requests. But some cached redirected requests could still have
HttpVaryData::is_valid_ == true.

Therefore some requests could reach a NOTREACHED() in
HttpVaryData::MatchesRequests() because comparing an HTTP request
vary that have a HttpVaryData::Init() now returning false because
no Vary from the request with a previously cached HttpVaryRequest
that have is_valid_ == true.

BUG= 611575 

Review-Url: https://codereview.chromium.org/2000123002
Cr-Commit-Position: refs/heads/master@{#395317}
(cherry picked from commit 7ec544a858f4dd2b5b3a0ad0949a1f24f55f10b4)

Review URL: https://codereview.chromium.org/2012463002 .

Cr-Commit-Position: refs/branch-heads/2743@{#30}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/ac453e0ec84fd9f1c87bf06080eca3a586f32bee/net/http/http_vary_data.cc