goma client: Fetching Google CRL sometimes 404s |
||
Issue descriptiongoma_auth.py often fails here (regardless of the command) because fetching http://crl.pki.goog/gsr2/gsr2.crl fails. I thought this was an issue on Intel's side (and sometimes switching network proxies solved the issue), but looking at /tmp/goma_fetch.WARNING I see several occurrences of 1123 12:22:22.813391 6325 http.cc:1892] downloadCrl read http=404 path=http://crl.pki.goog/gsr2/gsr2.crl Details:HTTP/1.1 404 Not Found\r\nContent-Type: text/html; charset=UTF-8\r\nReferrer-Policy: no-referrer\r\nContent-Length: 1574\r\nDate: Fri, 23 Nov 2018 11:22:22 GMT\r\nVia: 1.1 irdmzpr03, 1.1 irintpr02\r\nConnection: close\r\n\r\n<!DOCTYPE html>\n<html lang=en>\n <meta charset=utf-8>\n <meta name=viewport content=\"initial-scale=1, minimum-scale=1, width=device-width\">\n <title>Error 404 (Not Found)!!1</title>\n <style>\n *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}\n </style>\n <a href=//www.google.com/><span id=logo aria-label=Google></span></a>\n <p><b>404.</b> <ins>That\342\200\231s an error.</ins>\n <p>The requested URL <code>/gsr2/gsr2.crl</code> was not found on this server. <ins>That\342\200\231s all we know.</ins>\n Curiously, fetching that same file with e.g. curl or something else works 100% of the time.
,
Nov 26
The following revision refers to this bug: https://chromium.googlesource.com/infra/goma/client/+/87c2dd9f56e2e6801589868e6176db4b3d2a576b commit 87c2dd9f56e2e6801589868e6176db4b3d2a576b Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Date: Fri Nov 23 13:54:39 2018 Remove HttpClient::Options::http_host_name It is unclear from the Goma client's public history if this was ever used; it hasn't since the beginning of the public commits though. Get rid of all the code to avoid cruft and make things more readable. Bug: 908046 Change-Id: I7b876c3abb4232f0cc917717fb527ba175d936f7 [modify] https://crrev.com/87c2dd9f56e2e6801589868e6176db4b3d2a576b/client/http.cc [modify] https://crrev.com/87c2dd9f56e2e6801589868e6176db4b3d2a576b/client/http.h
,
Nov 26
The following revision refers to this bug: https://chrome-internal.googlesource.com/goma/client/+/3a17e8ef44b7b444f1448c55148818a3ccee7459 commit 3a17e8ef44b7b444f1448c55148818a3ccee7459 Author: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Date: Mon Nov 26 02:41:26 2018
,
Dec 4
The following revision refers to this bug: https://chromium.googlesource.com/infra/goma/client/+/b1361956547569b650063d5155ef957c8d1c3660 commit b1361956547569b650063d5155ef957c8d1c3660 Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Date: Tue Dec 04 07:39:23 2018 http: Also pass the destination host in the Host field for proxied HTTP connections This was previously being done only for HTTPS connections, and the public commit history is not clear on why. The previous behavior was to pass the proxy host's value in this situation, which resulted in an HTTP connection to the proxy host that looked like this: GET http://crl.pki.goog:80/GTSGIA3.crl HTTP/1.1 Host: my-proxy.com ... rather than GET http://crl.pki.goog:80/GTSGIA3.crl HTTP/1.1 Host: crl.pki.goog ... which, depending on the location we are connecting to, results in an error response (crl.pki.goog returns 404 for that certificate revocation list file, for example). Bug: chromium:908046 Change-Id: I484f32200b15402dbccd54ad127946ab03f52fc3 [modify] https://crrev.com/b1361956547569b650063d5155ef957c8d1c3660/client/http_unittest.cc [modify] https://crrev.com/b1361956547569b650063d5155ef957c8d1c3660/client/http.cc
,
Dec 4
,
Dec 4
The following revision refers to this bug: https://chrome-internal.googlesource.com/goma/client/+/46c87e22ec1f69e44ae40b40aee1f6a2a5feb3ce commit 46c87e22ec1f69e44ae40b40aee1f6a2a5feb3ce Author: Takuto Ikuta <tikuta@google.com> Date: Tue Dec 04 10:30:51 2018 |
||
►
Sign in to add a comment |
||
Comment 1 by raphael....@intel.com
, Nov 23This seems to be caused by bad HTTP headers when proxies are in use. HttpClient::Options::Host() has some proxy-handling logic in the form of if ((dest_host_name != SocketHost() || dest_port != SocketPort()) && use_ssl) { return dest_host_name; } which only matches when proxy_host_{name,port} are in use. The problematic part there is the |use_ssl| bit. It works most of the time since pretty much all communication Goma performs is encrypted. One of the exceptions is fetching the CRL via plain HTTP. In that case, the request to the proxy host ends up with a "Host" header set to the proxy host itself rather than "crl.pki.goog", which apparently causes Google's server to return a 404 error. Removing the "&& use_ssl" part solved all the problems here. While at it: HttpClient::Options::http_host_name was added when the Goma client as open-sourced, but nothing ever sets it anywhere.