24656 2009-03-17 15:58:49 -0700 cacheControlContainsNoCache() in ResourceResponseBase.h is wrong 2009-04-10 08:34:17 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) Mac OS X 10.5 RESOLVED FIXED P2 Normal --- 1 klobag ap ap darin ddkilzer fishd klobag koivisto oldest_to_newest 114120 0 klobag 2009-03-17 15:58:49 -0700 Here is the code, bool cacheControlContainsNoCache() const { if (!m_haveParsedCacheControl) parseCacheControlDirectives(); return m_m_cacheControlContainsMustRevalidate; } We should return m_cacheControlContainsNoCache instead 114148 1 klobag 2009-03-17 18:14:40 -0700 Another bug in the cpp file, ResourceResponseBase::parseCacheControlDirectives(). if ((equalIgnoringCase(directives[i].first, "private") || equalIgnoringCase(directives[i].first, "no-cache")) && !directives[i].second.isEmpty()) parseCacheControlDirectiveValues(directives[i].second, directiveValues); else directiveValues.append(directives[i].second); I think the else should append directives[i].first as directives[i].second is empty. 114161 2 28717 klobag 2009-03-17 19:39:54 -0700 Created attachment 28717 patch to fix the bug 114165 3 28717 sam 2009-03-17 22:48:14 -0700 Comment on attachment 28717 patch to fix the bug If you would like to put something up for review, you need to set the review flag to ?. This needs test cases, so r-. 114226 4 ap 2009-03-18 13:52:12 -0700 Hmm, this may be quite tricky to test for. A test could use a stateful script that would return different resource content each time, see e.g. http/tests/resources/network-simulator.php. 114244 5 klobag 2009-03-18 15:57:23 -0700 I found network-simulator.php too by searching "no-store". But I can't find the old test case when the code was added. It is really fixing a typo. Will work on a test case later. 115724 6 ap 2009-03-29 06:03:58 -0700 OK, I guess it's a bit unfair to strictly require tests, given that we've let the original patch in with no tests at all. But it also means that the tests are so much more important! > if ((equalIgnoringCase(directives[i].first, "private") || equalIgnoringCase(directives[i].first, "no-cache")) && !directives[i].second.isEmpty()) > parseCacheControlDirectiveValues(directives[i].second, directiveValues); > else > - directiveValues.append(directives[i].second); > + directiveValues.append(directives[i].first); This code looks busted in many more ways, and I don't think that it's very desirable to only fix one minor case. All this check does is stuff Cache-Control private and no-cache directive values into one bucket with other directives, which looks bogus. E.g., one possible use of this syntax is 'Cache-Control: no-cache="X-Foobar"', which means that 'X-Foobar' header must not be sent in a proxy response without revalidation. According to svn blame, this code was added in <http://trac.webkit.org/changeset/38145>. 115737 7 ddkilzer 2009-03-29 09:46:37 -0700 (In reply to comment #6) > > if ((equalIgnoringCase(directives[i].first, "private") || equalIgnoringCase(directives[i].first, "no-cache")) && !directives[i].second.isEmpty()) > > parseCacheControlDirectiveValues(directives[i].second, directiveValues); > > else > > - directiveValues.append(directives[i].second); > > + directiveValues.append(directives[i].first); > > This code looks busted in many more ways, and I don't think that it's very > desirable to only fix one minor case. All this check does is stuff > Cache-Control private and no-cache directive values into one bucket with other > directives, which looks bogus. E.g., one possible use of this syntax is > 'Cache-Control: no-cache="X-Foobar"', which means that 'X-Foobar' header must > not be sent in a proxy response without revalidation. The "private" and "no-cache" directive values are NOT put into a single bucket. You must read the second if/else statement below it to see how the directiveValues data is used. The check for "private" or "no-cache" in the code above is because the spec says that they are the only directives that may have one or more sub-values, so they are parsed differently than other directives. (But the code inside the outer for loop handles directives with and without sub-values, which may be why it's confusing.) See Section 14.9 in <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>. 115743 8 ddkilzer 2009-03-29 10:05:49 -0700 (In reply to comment #7) > (In reply to comment #6) > > > > if ((equalIgnoringCase(directives[i].first, "private") || equalIgnoringCase(directives[i].first, "no-cache")) && !directives[i].second.isEmpty()) > > > parseCacheControlDirectiveValues(directives[i].second, directiveValues); > > > else > > > - directiveValues.append(directives[i].second); > > > + directiveValues.append(directives[i].first); > > > > This code looks busted in many more ways, and I don't think that it's very > > desirable to only fix one minor case. All this check does is stuff > > Cache-Control private and no-cache directive values into one bucket with other > > directives, which looks bogus. E.g., one possible use of this syntax is > > 'Cache-Control: no-cache="X-Foobar"', which means that 'X-Foobar' header must > > not be sent in a proxy response without revalidation. > > The "private" and "no-cache" directive values are NOT put into a single bucket. > You must read the second if/else statement below it to see how the > directiveValues data is used. The check for "private" or "no-cache" in the > code above is because the spec says that they are the only directives that may > have one or more sub-values, so they are parsed differently than other > directives. (But the code inside the outer for loop handles directives with > and without sub-values, which may be why it's confusing.) I remember now, the parsing code was changed in r39383 because fully parsing the cache-control headers was a memory regression: <http://trac.webkit.org/changeset/39383> The original code I committed in r38145 did do correct parsing of those headers. - directiveValues.append(directives[i].second); + directiveValues.append(directives[i].first); This change is incorrect. - return m_cacheControlContainsMustRevalidate; + return m_cacheControlContainsNoCache; This change is correct and fixes a copy-paste error in cacheControlContainsNoCache(). If more detail is needed for Cache-Control headers (after r39383), you'll have to modify the parsing routines to check for what you're looking for and stuff it into a 1-bit bool field or return the data on an as-needed basis. 115744 9 ap 2009-03-29 10:08:31 -0700 Dave, please check how the current code handles e.g. "Cache-Control: private=must-revalidate" - instead of treating must-revalidate as a header name, it sets m_cacheControlContainsMustRevalidate to true. 115753 10 ddkilzer 2009-03-29 12:05:27 -0700 (In reply to comment #9) > Dave, please check how the current code handles e.g. "Cache-Control: > private=must-revalidate" - instead of treating must-revalidate as a header > name, it sets m_cacheControlContainsMustRevalidate to true. Yep, I agree that this broke in r39383. 115755 11 ddkilzer 2009-03-29 12:12:04 -0700 (In reply to comment #10) > (In reply to comment #9) > > Dave, please check how the current code handles e.g. "Cache-Control: > > private=must-revalidate" - instead of treating must-revalidate as a header > > name, it sets m_cacheControlContainsMustRevalidate to true. > > Yep, I agree that this broke in r39383. This is still the incorrect fix: - directiveValues.append(directives[i].second); + directiveValues.append(directives[i].first); Basically, the for() loop in ResourceResponseBase::parseCacheControlDirectives() that was added in r39383 needs to be fixed so it's checking for the must-revalidate keyword instead of a sub-value of a "private" or "no-cache" directive. I'll try to fix this soon-ish. 116870 12 29331 ap 2009-04-08 06:22:43 -0700 Created attachment 29331 proposed fix Let's get this fixed, at last. I'm actually not sure if a test can be made for this bug. 116878 13 29331 ddkilzer 2009-04-08 07:31:29 -0700 Comment on attachment 29331 proposed fix r=me 116879 14 ap 2009-04-08 07:36:55 -0700 Committed <http://trac.webkit.org/changeset/42319>. 116906 15 fishd 2009-04-08 11:01:06 -0700 Cache-control: no-cache="set-cookie" is actually quite common. 116911 16 ddkilzer 2009-04-08 11:54:25 -0700 (In reply to comment #15) > Cache-control: no-cache="set-cookie" is actually quite common. Darin, please file a new bug. Thanks! 116996 17 ap 2009-04-08 23:10:29 -0700 (In reply to comment #15) > Cache-control: no-cache="set-cookie" is actually quite common. What is the practical difference between no-cache and no-cache="set-cookie"? RFC 2616 seems to say that it's up to the cache to decide whether to send a cached response with Set-Cookie omitted, or to revalidate, which sounds confusing to me. 116998 18 fishd 2009-04-09 01:31:09 -0700 > What is the practical difference between no-cache and no-cache="set-cookie"? no-cache applies to the response body, no-cache="set-cookie" only applies to the set-cookie response header. practically speaking, no-cache="set-cookie" means that you should strip that cookie out when storing the response in the cache. otherwise, the response is totally cacheable. (in general, browser caches strip out set-cookie, but i guess there is probably some app server out there that likes to make sure... perhaps as information to proxy caches.) 117027 19 ap 2009-04-09 05:25:19 -0700 (In reply to comment #18) > practically speaking, no-cache="set-cookie" > means that you should strip that cookie out when storing the response in the > cache. What should the cache return when asked for this resource? It doesn't sound like returning a response without one of the headers makes much sense. 117047 20 fishd 2009-04-09 10:51:51 -0700 > What should the cache return when asked for this resource? It doesn't sound > like returning a response without one of the headers makes much sense. That's what it means. Think of it as a way for servers to specify that some information should be considered transient or private (can make good sense for set-cookie). HTTP caches also strip other transient (hop-by-hop) headers like Connection, etc. 117050 21 fishd 2009-04-09 10:57:34 -0700 From RFC 2616 section 14.9.1: If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 117063 22 ap 2009-04-09 12:40:48 -0700 (In reply to comment #21) > From RFC 2616 section 14.9.1: Yes, that's exactly the part that I was talking about. What confuses me is that a response that had a Set-Cookie header when sent to the first client is one that more than likely needs to have it when sent to other clients - it should obviously be different, but not missing. Is there a use case where a missing Set-Cookie header is fine? 117077 23 fishd 2009-04-09 14:53:23 -0700 > obviously be different, but not missing. Is there a use case where a missing > Set-Cookie header is fine? Perhaps a web developer might assume that the cookie would persist in the cookie database. One might need to combine this with cache-control: private to avoid strange proxy effects. Of course, the cookie could be absent in the cookie db :/ 117083 24 ddkilzer 2009-04-09 15:18:49 -0700 (In reply to comment #23) > > obviously be different, but not missing. Is there a use case where a missing > > Set-Cookie header is fine? > > Perhaps a web developer might assume that the cookie would persist in the > cookie database. One might need to combine this with cache-control: private to > avoid strange proxy effects. Of course, the cookie could be absent in the > cookie db :/ I don't understand how caching http proxy behavior applies to a web browser. Once the http request hits the browser, cookies have a different set of rules determining their cached lifetime than resources do. I don't see where no-cache="set-cookie" would have any bearing on a web browser. Or is Chrome's cache set up like a caching http proxy such that it needs to know when it can replay certain headers to each subprocess? 117092 25 fishd 2009-04-09 15:36:36 -0700 no, chrome's network stack does not act like a proxy. sorry to confuse matters. i mentioned proxies because that is something that web developers have to sometimes think about. i brought up the example of no-cache="set-cookie" because i have seen those in the wild. i'm only guessing why web developers (or more likely some web app engine) might want to send that in the response headers. most browsers do not store set-cookie response headers in the cache anyways, so this particular response header (no-cache="set-cookie") should indeed be irrelevant to browsers. however, what i found is that because no-cache="set-cookie" is common, if you do not discern no-cache="foo" from no-cache, then you will miss out on being able to cache a lot of content on the web. 117100 26 ddkilzer 2009-04-09 16:10:31 -0700 (In reply to comment #25) > however, what i found is that because no-cache="set-cookie" is common, if you > do not discern no-cache="foo" from no-cache, then you will miss out on being > able to cache a lot of content on the web. I see, so no-cache="set-cookie" should not prevent content from being cached. (In reply to comment #16) > Darin, please file a new bug. Thanks! Pretty please? :) 117122 27 fishd 2009-04-09 22:52:13 -0700 > I see, so no-cache="set-cookie" should not prevent content from being cached. Right. > (In reply to comment #16) > > Darin, please file a new bug. Thanks! > > Pretty please? :) Sorry, I missed that comment before. See bug 25129. 117138 28 ap 2009-04-10 02:16:49 -0700 (In reply to comment #23) > Perhaps a web developer might assume that the cookie would persist in the > cookie database. One might need to combine this with cache-control: private to > avoid strange proxy effects. AFAICT cache-control: private also makes no-cache="set-cookie" unnecessary. So, I'm still confused about the utility of such directive, but it does seem like we should not treat it as no-cache indeed. Have you ever seen no-cache=... with other header names in practice? Set-cookie2 maybe? 117145 29 fishd 2009-04-10 08:34:17 -0700 > AFAICT cache-control: private also makes no-cache="set-cookie" unnecessary. So, > I'm still confused about the utility of such directive, but it does seem like > we should not treat it as no-cache indeed. Have you ever seen no-cache=... with > other header names in practice? Set-cookie2 maybe? Using a tool I know of to search the web, I found some instances of cache-control no-cache="set-cookie,set-cookie2". I see no-cache="server" here: http://www.w3.org/Protocols/HTTP/Issues/cachedirective.txt 28717 2009-03-17 19:39:54 -0700 2009-04-08 06:22:43 -0700 patch to fix the bug patch.txt text/plain 2248 klobag SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0MTc5NikKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTQgQEAKKzIwMDktMDMtMTcgIEdyYWNlIEtsb2JhICA8a2xvYmFnQGdtYWlsLmNv bT4KKworICAgICAgICBGaXggaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTI0NjU2LgorICAgICAgICBTaG91bGQgcmV0dXJuIG1fY2FjaGVDb250cm9sQ29udGFpbnNOb0Nh Y2hlIGZvciBjYWNoZUNvbnRyb2xDb250YWluc05vQ2FjaGUoKS4KKyAgICAgICAgV2hlbiBkaXJl Y3RpdmVzW2ldLnNlY29uZC5pc0VtcHR5KCksIHdlIHNob3VsZCBhcHBlbmQgZGlyZWN0aXZlc1tp XS5maXJzdCB0byBkaXJlY3RpdmVWYWx1ZXMuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9uZXR3b3Jr L1Jlc291cmNlUmVzcG9uc2VCYXNlLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlJlc291cmNlUmVz cG9uc2VCYXNlOjpwYXJzZUNhY2hlQ29udHJvbERpcmVjdGl2ZXMpOgorICAgICAgICAqIHBsYXRm b3JtL25ldHdvcmsvUmVzb3VyY2VSZXNwb25zZUJhc2UuaDoKKyAgICAgICAgKFdlYkNvcmU6OlJl c291cmNlUmVzcG9uc2VCYXNlOjpjYWNoZUNvbnRyb2xDb250YWluc05vQ2FjaGUpOgorCiAyMDA5 LTAzLTE3ICBEYXZpZCBDYXJzb24gIDxkYWNhcnNvbkBhcHBsZS5jb20+CiAKICAgICAgICAgUmV2 aWV3ZWQgYnkgRGF2aWQgSHlhdHQuCkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvUmVz b3VyY2VSZXNwb25zZUJhc2UuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGxhdGZvcm0vbmV0 d29yay9SZXNvdXJjZVJlc3BvbnNlQmFzZS5jcHAJKHJldmlzaW9uIDQxNzk2KQorKysgV2ViQ29y ZS9wbGF0Zm9ybS9uZXR3b3JrL1Jlc291cmNlUmVzcG9uc2VCYXNlLmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMjM5LDcgKzIzOSw3IEBAIHZvaWQgUmVzb3VyY2VSZXNwb25zZUJhc2U6OnBhcnNlQ2Fj aGVDb24KICAgICAgICAgaWYgKChlcXVhbElnbm9yaW5nQ2FzZShkaXJlY3RpdmVzW2ldLmZpcnN0 LCAicHJpdmF0ZSIpIHx8IGVxdWFsSWdub3JpbmdDYXNlKGRpcmVjdGl2ZXNbaV0uZmlyc3QsICJu by1jYWNoZSIpKSAmJiAhZGlyZWN0aXZlc1tpXS5zZWNvbmQuaXNFbXB0eSgpKQogICAgICAgICAg ICAgcGFyc2VDYWNoZUNvbnRyb2xEaXJlY3RpdmVWYWx1ZXMoZGlyZWN0aXZlc1tpXS5zZWNvbmQs IGRpcmVjdGl2ZVZhbHVlcyk7CiAgICAgICAgIGVsc2UKLSAgICAgICAgICAgIGRpcmVjdGl2ZVZh bHVlcy5hcHBlbmQoZGlyZWN0aXZlc1tpXS5zZWNvbmQpOworICAgICAgICAgICAgZGlyZWN0aXZl VmFsdWVzLmFwcGVuZChkaXJlY3RpdmVzW2ldLmZpcnN0KTsKICAgICAgICAgZm9yIChzaXplX3Qg aSA9IDA7IGkgPCBkaXJlY3RpdmVWYWx1ZXMuc2l6ZSgpOyArK2kpIHsKICAgICAgICAgICAgIGlm IChlcXVhbElnbm9yaW5nQ2FzZShkaXJlY3RpdmVWYWx1ZXNbaV0sICJuby1jYWNoZSIpKQogICAg ICAgICAgICAgICAgIG1fY2FjaGVDb250cm9sQ29udGFpbnNOb0NhY2hlID0gdHJ1ZTsKSW5kZXg6 IFdlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9SZXNvdXJjZVJlc3BvbnNlQmFzZS5oCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIFdlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9SZXNvdXJjZVJlc3BvbnNlQmFzZS5oCShy ZXZpc2lvbiA0MTc5NikKKysrIFdlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9SZXNvdXJjZVJlc3Bv bnNlQmFzZS5oCSh3b3JraW5nIGNvcHkpCkBAIC04OCw3ICs4OCw3IEBAIHB1YmxpYzoKICAgICB7 CiAgICAgICAgIGlmICghbV9oYXZlUGFyc2VkQ2FjaGVDb250cm9sKQogICAgICAgICAgICAgcGFy c2VDYWNoZUNvbnRyb2xEaXJlY3RpdmVzKCk7Ci0gICAgICAgIHJldHVybiBtX2NhY2hlQ29udHJv bENvbnRhaW5zTXVzdFJldmFsaWRhdGU7CisgICAgICAgIHJldHVybiBtX2NhY2hlQ29udHJvbENv bnRhaW5zTm9DYWNoZTsKICAgICB9CiAgICAgYm9vbCBjYWNoZUNvbnRyb2xDb250YWluc011c3RS ZXZhbGlkYXRlKCkgY29uc3QKICAgICB7Cg== 29331 2009-04-08 06:22:43 -0700 2009-04-08 07:31:29 -0700 proposed fix CacheControlParsing.txt text/plain 3836 ap SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0MjMxNykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTggQEAKKzIwMDktMDQtMDggIEFsZXhleSBQcm9za3VyeWFrb3YgIDxhcEB3ZWJr aXQub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLiBCYXNlZCBvbiBh IHBhdGNoIGJ5IEdyYWNlIEtsb2JhLgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3Jn L3Nob3dfYnVnLmNnaT9pZD0yNDY1NgorICAgICAgICBjYWNoZUNvbnRyb2xDb250YWluc05vQ2Fj aGUoKSBpbiBSZXNvdXJjZVJlc3BvbnNlQmFzZS5oIGlzIHdyb25nCisKKyAgICAgICAgKiBwbGF0 Zm9ybS9uZXR3b3JrL1Jlc291cmNlUmVzcG9uc2VCYXNlLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6 OlJlc291cmNlUmVzcG9uc2VCYXNlOjpwYXJzZUNhY2hlQ29udHJvbERpcmVjdGl2ZXMpOiBSZW1v dmVkIG1pc3VzZWQgY29kZSBmb3IKKyAgICAgICAgcGFyc2luZyBkaXJlY3RpdmUgdmFsdWVzLCBm aXhpbmcgcGFyc2luZyBvZiBkaXJlY3RpdmVzIHRoYXQgd2UgY2FyZSBhYm91dC4KKworICAgICAg ICAqIHBsYXRmb3JtL25ldHdvcmsvUmVzb3VyY2VSZXNwb25zZUJhc2UuaDoKKyAgICAgICAgKFdl YkNvcmU6OlJlc291cmNlUmVzcG9uc2VCYXNlOjpjYWNoZUNvbnRyb2xDb250YWluc05vQ2FjaGUp OiBGaXhlZCBhIGNvcHkvcGFzdGUgbWlzdGFrZSwKKyAgICAgICAgbV9jYWNoZUNvbnRyb2xDb250 YWluc011c3RSZXZhbGlkYXRlIHdhcyByZXR1cm5lZCBpbnN0ZWFkIG9mIG1fY2FjaGVDb250cm9s Q29udGFpbnNOb0NhY2hlLgorCiAyMDA5LTA0LTA4ICBBZGFtIFJvYmVuICA8YXJvYmVuQGFwcGxl LmNvbT4KIAogICAgICAgICBNYWtlIHRleHQgZmllbGRzIG1hdGNoIHRoZSBzeXN0ZW0gbG9vayBv biBWaXN0YQpJbmRleDogV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL1Jlc291cmNlUmVzcG9uc2VC YXNlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvUmVzb3VyY2VS ZXNwb25zZUJhc2UuY3BwCShyZXZpc2lvbiA0MjMxMykKKysrIFdlYkNvcmUvcGxhdGZvcm0vbmV0 d29yay9SZXNvdXJjZVJlc3BvbnNlQmFzZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTM0LDcgKzM0 LDYgQEAgdXNpbmcgbmFtZXNwYWNlIHN0ZDsKIG5hbWVzcGFjZSBXZWJDb3JlIHsKIAogc3RhdGlj IHZvaWQgcGFyc2VDYWNoZUhlYWRlcihjb25zdCBTdHJpbmcmIGhlYWRlciwgVmVjdG9yPHBhaXI8 U3RyaW5nLCBTdHJpbmc+ID4mIHJlc3VsdCk7Ci1zdGF0aWMgdm9pZCBwYXJzZUNhY2hlQ29udHJv bERpcmVjdGl2ZVZhbHVlcyhjb25zdCBTdHJpbmcmIGRpcmVjdGl2ZXMsIFZlY3RvcjxTdHJpbmc+ JiByZXN1bHQpOwogCiBhdXRvX3B0cjxSZXNvdXJjZVJlc3BvbnNlPiBSZXNvdXJjZVJlc3BvbnNl QmFzZTo6YWRvcHQoYXV0b19wdHI8Q3Jvc3NUaHJlYWRSZXNvdXJjZVJlc3BvbnNlRGF0YT4gZGF0 YSkKIHsKQEAgLTIzNSwxNyArMjM0LDExIEBAIHZvaWQgUmVzb3VyY2VSZXNwb25zZUJhc2U6OnBh cnNlQ2FjaGVDb24KIAogICAgIHNpemVfdCBkaXJlY3RpdmVzU2l6ZSA9IGRpcmVjdGl2ZXMuc2l6 ZSgpOwogICAgIGZvciAoc2l6ZV90IGkgPSAwOyBpIDwgZGlyZWN0aXZlc1NpemU7ICsraSkgewot ICAgICAgICBWZWN0b3I8U3RyaW5nPiBkaXJlY3RpdmVWYWx1ZXM7Ci0gICAgICAgIGlmICgoZXF1 YWxJZ25vcmluZ0Nhc2UoZGlyZWN0aXZlc1tpXS5maXJzdCwgInByaXZhdGUiKSB8fCBlcXVhbEln bm9yaW5nQ2FzZShkaXJlY3RpdmVzW2ldLmZpcnN0LCAibm8tY2FjaGUiKSkgJiYgIWRpcmVjdGl2 ZXNbaV0uc2Vjb25kLmlzRW1wdHkoKSkKLSAgICAgICAgICAgIHBhcnNlQ2FjaGVDb250cm9sRGly ZWN0aXZlVmFsdWVzKGRpcmVjdGl2ZXNbaV0uc2Vjb25kLCBkaXJlY3RpdmVWYWx1ZXMpOwotICAg ICAgICBlbHNlCi0gICAgICAgICAgICBkaXJlY3RpdmVWYWx1ZXMuYXBwZW5kKGRpcmVjdGl2ZXNb aV0uc2Vjb25kKTsKLSAgICAgICAgZm9yIChzaXplX3QgaSA9IDA7IGkgPCBkaXJlY3RpdmVWYWx1 ZXMuc2l6ZSgpOyArK2kpIHsKLSAgICAgICAgICAgIGlmIChlcXVhbElnbm9yaW5nQ2FzZShkaXJl Y3RpdmVWYWx1ZXNbaV0sICJuby1jYWNoZSIpKQotICAgICAgICAgICAgICAgIG1fY2FjaGVDb250 cm9sQ29udGFpbnNOb0NhY2hlID0gdHJ1ZTsKLSAgICAgICAgICAgIGVsc2UgaWYgKGVxdWFsSWdu b3JpbmdDYXNlKGRpcmVjdGl2ZVZhbHVlc1tpXSwgIm11c3QtcmV2YWxpZGF0ZSIpKQotICAgICAg ICAgICAgICAgIG1fY2FjaGVDb250cm9sQ29udGFpbnNNdXN0UmV2YWxpZGF0ZSA9IHRydWU7Ci0g ICAgICAgIH0KKyAgICAgICAgLy8gVGhlIG5vLWNhY2hlIGRpcmVjdGl2ZSBjYW4gaGF2ZSBhIHZh bHVlLCB3aGljaCBpcyBpZ25vcmVkIGhlcmUuIFRoaXMgbWVhbnMgdGhhdCBpbiB2ZXJ5IHJhcmUg Y2FzZXMsIHJlc3BvbnNlcyB0aGF0IGNvdWxkIGJlIHRha2VuIGZyb20gY2FjaGUgd29uJ3QgYmUu CisgICAgICAgIGlmIChlcXVhbElnbm9yaW5nQ2FzZShkaXJlY3RpdmVzW2ldLmZpcnN0LCAibm8t Y2FjaGUiKSkKKyAgICAgICAgICAgIG1fY2FjaGVDb250cm9sQ29udGFpbnNOb0NhY2hlID0gdHJ1 ZTsKKyAgICAgICAgZWxzZSBpZiAoZXF1YWxJZ25vcmluZ0Nhc2UoZGlyZWN0aXZlc1tpXS5maXJz dCwgIm11c3QtcmV2YWxpZGF0ZSIpKQorICAgICAgICAgICAgbV9jYWNoZUNvbnRyb2xDb250YWlu c011c3RSZXZhbGlkYXRlID0gdHJ1ZTsKICAgICB9CiB9CiAKQEAgLTQxNCwxMiArNDA3LDQgQEAg c3RhdGljIHZvaWQgcGFyc2VDYWNoZUhlYWRlcihjb25zdCBTdHJpbgogICAgIH0KIH0KIAotc3Rh dGljIHZvaWQgcGFyc2VDYWNoZUNvbnRyb2xEaXJlY3RpdmVWYWx1ZXMoY29uc3QgU3RyaW5nJiBk aXJlY3RpdmVzLCBWZWN0b3I8U3RyaW5nPiYgcmVzdWx0KQotewotICAgIGRpcmVjdGl2ZXMuc3Bs aXQoJywnLCBmYWxzZSwgcmVzdWx0KTsKLSAgICB1bnNpZ25lZCBtYXggPSByZXN1bHQuc2l6ZSgp OwotICAgIGZvciAodW5zaWduZWQgaSA9IDA7IGkgPCBtYXg7ICsraSkKLSAgICAgICAgcmVzdWx0 W2ldID0gcmVzdWx0W2ldLnN0cmlwV2hpdGVTcGFjZSgpOwotfQotCiB9CkluZGV4OiBXZWJDb3Jl L3BsYXRmb3JtL25ldHdvcmsvUmVzb3VyY2VSZXNwb25zZUJhc2UuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBX ZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvUmVzb3VyY2VSZXNwb25zZUJhc2UuaAkocmV2aXNpb24g NDIzMTMpCisrKyBXZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvUmVzb3VyY2VSZXNwb25zZUJhc2Uu aAkod29ya2luZyBjb3B5KQpAQCAtODgsNyArODgsNyBAQCBwdWJsaWM6CiAgICAgewogICAgICAg ICBpZiAoIW1faGF2ZVBhcnNlZENhY2hlQ29udHJvbCkKICAgICAgICAgICAgIHBhcnNlQ2FjaGVD b250cm9sRGlyZWN0aXZlcygpOwotICAgICAgICByZXR1cm4gbV9jYWNoZUNvbnRyb2xDb250YWlu c011c3RSZXZhbGlkYXRlOworICAgICAgICByZXR1cm4gbV9jYWNoZUNvbnRyb2xDb250YWluc05v Q2FjaGU7CiAgICAgfQogICAgIGJvb2wgY2FjaGVDb250cm9sQ29udGFpbnNNdXN0UmV2YWxpZGF0 ZSgpIGNvbnN0CiAgICAgewo=