opened against wrong component, probably should be Internals>Network>Auth

[asanka]:  We don't expire old auth entries, right?

We don't expire entries based on age alone. An entry can get evicted if there are lots of new entries being added. This would be the case if one was using lots of URL embedded credentials.

OP: Do you have a few sites open with HTTP authentication, or do you have a number of authenticated resources being accessed during this time? Perchance, do you have a page with a bunch of resources which are fetched via URLs with embedded credentials?

Yeah there were a few sites open/a number of authenticated resources being accessed during this time with HTTP authentication (~10 sites, ~30 tabs running at all time with new tabs/windows being constantly opened/closed). Basically everything under the most used domains have HTTP authentication. No URLs with embedded credentials.

On Linux I have not opened as many HTTP authenticated tabs as I did on MacOS. It could possibly affect other platforms as well.

Thank you for providing more feedback. Adding requester "asanka@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@ legendmove--Could you please help us with the sample url/website to reproduce the issue as we have tried with https sites and couldn't observe the issue.

Thanks!

The sites are internal. Is there anyway I can collect troubleshooting information related to HTTP auth? 

The issue happens at random intervals. Often if I leave the browser idle for days (e.g for the weekend), it is fine when I use it again. But for tabs I use often, it is more likely to lose HTTP auth and then I have to log into every site behind HTTP auth again. 

I tried Chromium update, closing all Chromium processes, rebooting the computer. None of these helped.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@asanka-- Could you please check and respond to the comment #6 and help us in further traiging .

Thanks!

Are there more than 10 distinct sets of credentials in use?

The current limit is 10. If any website (including ads and such) request a resource via a URL with an embedded credential which ends up being used to respond to a HTTP 401, then that'll cause one of the cached credentials to be evicted.

A net-internals log could identify the cause accurately, but I don't think a log is practical if it's going to take a long time to replicate the issue. That'll result in a prohibitively large log.

~5 sets of credentials, but +10 FQDNs (some sharing the same credentials). Different web servers/different authentication backend

By embedded credential, do you mean the html like https://username:password@fqdn ? AFAIK there isn't any in my environment.

In my experience, every HTTP authentication tends to get invalidated at the same time (have to re-enter password on every FQDN).

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to triage this issue from TE-End, hence adding TE-NeedsTriageHelp label for further triage 

#13: Credentials are managed by origin among other dimensions. So if you are doing BASIC authentication for 10 FQDNs, you're hitting the limit :-(. Also, once you hit the limit, every new credential you enter will cause an older set to be evicted, which may cause you to re-enter all credentials.

This is one of the cases where we'd need to raise the cache limit, or get rid of it.

10 hosts limit seems quite low. In my case I probably have well over 10 due to some pages loading resources from several hosts.

Yup. Agreed that 10 is quite low.

I'm new to Chromium dev, and there has already been a lot of conversation on this issue, so I'm not sure if it's state, but is there anything I can do to help?

Thanks for checking. The problem is well understood. It's just a matter of prioritizing a fix.

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

commit 7dad1c4475b73eacba0029db21683bcda832f8c7
Author: Lily Chen <chlily@chromium.org>
Date: Fri Oct 05 21:42:09 2018

Add a histogram to track HTTP auth cache size

This change adds a histogram that tracks the number of cache entries
examined when no matching entry is found (which is most of the time).
This will allow us to have a better proxy for HTTP auth cache size.

Bug:  757116 
Change-Id: I8a4b7348a473d2802ac12dda2589569e523b3e5e
Reviewed-on: https://chromium-review.googlesource.com/c/1265435
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Commit-Queue: Lily Chen <chlily@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597314}
[modify] https://crrev.com/7dad1c4475b73eacba0029db21683bcda832f8c7/net/http/http_auth_cache.cc
[modify] https://crrev.com/7dad1c4475b73eacba0029db21683bcda832f8c7/tools/metrics/histograms/histograms.xml

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

commit f714efa853d528597f08b58a8c656975836a45c9
Author: Lily Chen <chlily@chromium.org>
Date: Tue Oct 09 21:09:47 2018

Reorder HTTP auth cache entries and paths when they are accessed

Whenever a query for an HTTP auth cache entry finds a matching entry,
that entry is moved up by one place in the list of entries. Similarly,
whenever a matching path is found in the paths list for an entry, that
path is moved up by one place. This causes the most frequently used
entries and paths to migrate towards the beginning of the list.

Bug:  757116 
Change-Id: I66aa9ac7ea77f13f25bf8351059035a8949182ab
Reviewed-on: https://chromium-review.googlesource.com/c/1268737
Reviewed-by: Asanka Herath <asanka@chromium.org>
Commit-Queue: Lily Chen <chlily@chromium.org>
Cr-Commit-Position: refs/heads/master@{#598080}
[modify] https://crrev.com/f714efa853d528597f08b58a8c656975836a45c9/net/http/http_auth_cache.cc
[modify] https://crrev.com/f714efa853d528597f08b58a8c656975836a45c9/net/http/http_auth_cache.h
[modify] https://crrev.com/f714efa853d528597f08b58a8c656975836a45c9/net/http/http_auth_cache_unittest.cc

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

commit e099b1d1a9153dc8a2caccf9b37ae02d365b9cd1
Author: Lily Chen <chlily@chromium.org>
Date: Fri Oct 12 21:28:55 2018

Change HTTP Auth Cache from a list to a multimap

Previously, the HTTP Auth Cache was implemented as a list of auth
entries, which was searched linearly for a matching entry upon lookup.
This change converts the cache to a multimap keyed on the origin, which
is expected to provide faster lookups in cases where there are no
matching entries for a given origin (which is the majority of cases).
This will also allow for a higher cache size limit without a linear
increase in lookup time, hence the cache size limit is raised from 10 to
20. This is expected to lower the rate of evictions upon adding entries.
Obsolete histograms which no longer apply to the new implementation are
also removed.

Bug:  757116 , 614108
Change-Id: Iabd2104b2d1c38d474450978a712039819b038e6
Reviewed-on: https://chromium-review.googlesource.com/c/1273820
Commit-Queue: Lily Chen <chlily@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599362}
[modify] https://crrev.com/e099b1d1a9153dc8a2caccf9b37ae02d365b9cd1/net/http/http_auth_cache.cc
[modify] https://crrev.com/e099b1d1a9153dc8a2caccf9b37ae02d365b9cd1/net/http/http_auth_cache.h
[modify] https://crrev.com/e099b1d1a9153dc8a2caccf9b37ae02d365b9cd1/net/http/http_auth_cache_unittest.cc
[modify] https://crrev.com/e099b1d1a9153dc8a2caccf9b37ae02d365b9cd1/tools/metrics/histograms/histograms.xml