Could you please provide a chrome://net-export log?  Instructions:  https://dev.chromium.org/for-testers/providing-network-details

Adding logs for the issue

Deleted: Issue_863292_logs.json 1.1 MB

Issue_863292_logs.json 1.1 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Looks like an error is returned by the HTTP2 proxy.  Not sure why we don't display the specific HTTP2 error message to the user:

t=35319 [st=12539]    HTTP2_SESSION_SEND_HEADERS
                      --> exclusive = true
                      --> fin = false
                      --> has_priority = true
                      --> :method: CONNECT
                          :authority: www.akamaidevops.com:443
                          user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
                      --> parent_stream_id = 0
                      --> source_dependency = 1442 (PROXY_CLIENT_SOCKET_WRAPPER)
                      --> stream_id = 7
                      --> weight = 220
t=35328 [st=12548]    HTTP2_SESSION_RECV_GOAWAY
                      --> active_streams = 1
                      --> debug_data = "[0 bytes were stripped]"
                      --> error_code = "9 (COMPRESSION_ERROR)"
                      --> last_accepted_stream_id = 7
                      --> unclaimed_streams = 0

So I assume either your proxy has a bug in reading compressed headers, or chromium has a bug in sending them.

I am using the Chrome proxy API https://developer.chrome.com/extensions/proxy to handle the proxy connections, so not sure if we can built something to handle the error occurring within a proxy session. 

is there a way to check if chromium is mishandling the request? 

Here is another one where I tried it with HTTP1.1, this time I get a ERR_TUNNEL_CONNECTION_FAILED

Deleted: issue-863292-http1dot1.json 248 KB

issue-863292-http1dot1.json 248 KB View Download

Taking out the relevant bits, we get (I'm not sure why we send a funky user-agent to proxies - I'd guess because renderer-initiated requests include their own user agent header, masking the weird one set by the browser process.  Requests that don't use the proxy look to have more standard headers.  Regarldess, doesn't seem important here).

t=2554 [st=36]          HTTP_TRANSACTION_SEND_TUNNEL_HEADERS
                        --> CONNECT clients4.google.com:443 HTTP/1.1
                            Host: clients4.google.com:443
                            Proxy-Connection: keep-alive
                            User-Agent: Chrome MAC 67.0.3396.99 (a337fbf3c2ab8ebc6b64b0bfdce73a20e2e2252b-refs/branch-heads/3396@{#790}) channel(stable)
t=2567 [st=49]          HTTP_TRANSACTION_READ_TUNNEL_RESPONSE_HEADERS
                        --> HTTP/1.0 400 Bad Request
                            Server: AkamaiGHost
                            Mime-Version: 1.0
                            Content-Type: text/html
                            Content-Length: 216
                            Expires: Thu, 19 Jul 2018 03:18:33 GMT
                            Date: Thu, 19 Jul 2018 03:18:33 GMT
                            Connection: close

So we send a tunnel request, and the proxy tells us it's a bad request.  This is very similar to HTTP2 log.  Are you sure your proxy server supports tunneled requests (Mostly HTTPS and occasionally WSS), and not just HTTP requests?

yes, the Server does support both https and WSS traffic. When I hit the server directly I do get the content just that when I go through the Chrome proxy API implementation the requests fail. 

Here is the link to the extension if you would like to reproduce the issue https://chrome.google.com/webstore/detail/akamai-developer-toolkit/oeekflkhfpllpepjdkpodopelgaebeed 

Tried it against an AWS cloudfront server as well https://origin-03300eb-www.akamaidevops.com/ gives me the same error 

Chrome proxy settings
Proxy server: https://origin-03300eb-www.akamaidevops.com:443
Bypass list: 
  *.*.akamaiapis.net
  127.0.0.1/8
  10.0.0.0/8
  172.16.0.0/12
  192.168.0.0/16
  <local>

When you hit the server directly?  Are you using it as a tunnel, or expecting the server to serve HTTPS responses directly?  Regardless, I don't think we can make any forward progress here - the server claims requests are bad for unknown reasons.  Chrome works fine with other proxies.  I'd tend to blame the proxy, without any more information (The proxy needs to support ~4 HTTP stacks.  Chrome must work with thousands of different proxies, and we haven't had any other reports like this).

That doesn't prove where the issue is, but unfortunately, we have to pick which issues to spend time digging into.

Thanks, it makes sense where to invest time and effort from the Chrome side of things. 

As for the question you asked, I was expecting the server to provide HTTPS response directly. Just out of curiosity - What's the difference between a tunneled request versus expecting a HTTPs response directly from a server?

BTW the "bad request" response from an Akamai server is because we don't have client4.google.com configured in our servers to respond. But Akamai servers does have www.akamaidevops.com configured to respond. 

With a tunneled request, we tell the proxy to connect to the destination server.  Then the proxy tells us it has established a connection.  Then we negotiate an SSL connection with the destination server like normal, so the proxy can't see the decrypted contents of the request.  The is the only way we support HTTPS/WSS over proxies.

If a proxy wants to be able to perform a man-in-the-middle style attack (Or whatever) on the connection, the proxy must perform SSL negotiation with the client over that socket, and client must be set to trust the bogus cert the proxy offers for the destination site.

There is no connection to www.akamaidevops.com in the HTTP/1.x log you uploaded.  I'd be happy to take a look at another log, if you uploaded it.

the HTTP/1.x has the logs for accessing the object https://http1.akamai.com/demo/tile-1.png , this is configured on our servers as well. 

The request for a socket for https://http1.akamai.com/demo/tile-1.png looks identical the one for the client4.google.com resource:

t=4013 [st=29]          HTTP_TRANSACTION_SEND_TUNNEL_HEADERS
                        --> CONNECT http1.akamai.com:443 HTTP/1.1
                            Host: http1.akamai.com:443
                            Proxy-Connection: keep-alive
                            User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

t=4028 [st=44]          HTTP_TRANSACTION_READ_TUNNEL_RESPONSE_HEADERS
                        --> HTTP/1.0 400 Bad Request
                            Server: AkamaiGHost
                            Mime-Version: 1.0
                            Content-Type: text/html
                            Content-Length: 216
                            Expires: Thu, 19 Jul 2018 03:18:35 GMT
                            Date: Thu, 19 Jul 2018 03:18:35 GMT
                            Connection: close

I'm going to go ahead and close this, as most likely a proxy configuration issue, however, if you find something that indicates Chrome is doing something specifically wrong, I'm happy to reopen and fix it.

My reading of this bug is that you are trying to use AkamaiGHost as an HTTPS proxy server, and it does not support the CONNECT method.

Agreed that this is not a Chrome bug.