Header logging lacking specifically for requests that hit in cache |
|||
Issue descriptionIn investigating issue 746421 , the reported netlog showed CONTENT_DECODING_FAILED reported from https://chromium.googlesource.com/chromium/src/+blame/master/net/http/http_network_transaction.cc#1236 . However, header logging in HttpNetworkTransaction occurs after that point, so it was not possible to observed the headers returned from the server and confirm that the Accept-Encoding provided by the client was being ignored by the server. That problem's easy to remedy by moving the header logging earlier in HttpNetworkTransaction::DoReadHeadersComplete. However, it brings up another background concern I have, which is that if a request hits in cache no headers (request or response) are shown, and if a request is not satisfied from an existing cache entry, no data (like request/response headers) is given for why the request isn't satisfied. However, it would be pretty easy to dump a whole lot more data into the netlog, without necessarily improving debuggability, so I wanted to consult with the relevant people before I put a lot of effort in this direction. I have a simple modification in https://chromium-review.googlesource.com/582390 which unilaterally outputs the response headers from a cache entry before it goes into cache validation. An example of the results is attached; event 1880 is an example of a cache hit, 2007 is an example of a stale cache entry being validated, and 1937 an example of a read from cache that was DOA resulting in a regular network fetch. Any opinions about what the best options here would be? Specific questions: * Under what circumstances (include never and always) should the request headers be shown when interacting with the cache? Currently the only place the request headers are shown is if there's a network request, so maybe the ideal would be only if the request is fully satisfied from cache? * Ditto response headers; note that unlike request these can be different cache/network. * How important is it for the cache to log information about why it didn't like an entry it retrieved and thus to go on to read from the network? Any thoughts?
,
Jul 24 2017
So I just did a test (www.harvard.edu + reload to get cache cases) and the difference was noise (i.e. the output log was smaller when I write the headers than when I don't, which I gotta believe is because of random differences in the loaded. I did delete the user data dir in between.) 251.7K vs 252.2K. This includes outputting the response headers in both places, but not the request headers. (I keep flip-flopping on the request headers; they are changed as they go through the stack, so outputting them in both places is arguably a good idea, but they're going to be *almost* identical, so it seems like a waste.) Having said that, I'm more worried about extra garbage confusing debugging than I am about size. Of course, it may be a little late to worry about that for netlogs :-}.
,
Jul 24 2017
Hrm... It does seem a bit weird to have cached response headers before the request headers that directed us to them, but not having any cache headers at all, even for responses served fully out of the cache, has long been a headache.
,
Jul 24 2017
So how do you feel about both cache and network transactions outputting request headers?
,
Jul 26 2017
Proposal: Unilaterally log request *and* response headers at the beginning of DoCacheReadResponseComplete. I'll also aim to put in a log for CacheEntryStatus, but I'm hoping Shivani or Josh can guide me on where that should be--I'd think it would be as we leave HttpCacheTransaction, but I would imagine that can happen from a couple of different states. Speak now or ... well, hold your piece until the code review :-}.
,
Jul 26 2017
I think you mean peace. If people are holding their pieces during a codereview...Well, I've never heard of code rage being a thing, but you never know.
,
Jul 26 2017
*chuckle* Yes, I did mean peace. And I envy you that you've never heard of code rage being a thing :-}.
,
Feb 16 2018
Sorry, this isn't going to happen before I leave Chromium development.
,
Nov 16
|
|||
►
Sign in to add a comment |
|||
Comment 1 by jkarlin@chromium.org
, Jul 24 2017