Could you attach a net-internals log? Details are here: https://dev.chromium.org/for-testers/providing-network-details

You can leave the "Strip private information" option on so that the actual auth credentials will be stripped. But the remainder of the network details should help us figure out what's going on between the browser and the server.

For what it's worth, I cannot reproduce on 63.0.3230.0.  Network logs confirm that authentication takes place and that response is gzipped, but it displays correctly every single time.

947: URL_REQUEST
http://localhost/
Start Time: 2017-10-09 11:17:23.135

t= 771 [st=   0] +REQUEST_ALIVE  [dt=2775]
                  --> priority = "HIGHEST"
                  --> url = "http://localhost/"
t= 771 [st=   0]    URL_REQUEST_DELEGATE  [dt=0]
t= 771 [st=   0]   +URL_REQUEST_START_JOB  [dt=2771]
                    --> load_flags = 37120 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> url = "http://localhost/"
t= 771 [st=   0]      URL_REQUEST_DELEGATE  [dt=0]
t= 771 [st=   0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t= 771 [st=   0]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                      --> net_error = -2 (ERR_FAILED)
t= 771 [st=   0]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t= 771 [st=   0]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t= 771 [st=   0]     +HTTP_STREAM_REQUEST  [dt=143]
t= 771 [st=   0]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                        --> source_dependency = 950 (HTTP_STREAM_JOB_CONTROLLER)
t= 914 [st= 143]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                        --> source_dependency = 961 (HTTP_STREAM_JOB)
t= 914 [st= 143]     -HTTP_STREAM_REQUEST
t= 914 [st= 143]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t= 914 [st= 143]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                        --> GET / HTTP/1.1
                            Host: localhost
                            Connection: keep-alive
                            User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3230.0 Safari/537.36
                            Upgrade-Insecure-Requests: 1
                            Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            Accept-Encoding: gzip, deflate, br
                            Accept-Language: en-US,en;q=0.9,hu;q=0.8
t= 914 [st= 143]     -HTTP_TRANSACTION_SEND_REQUEST
t= 914 [st= 143]     +HTTP_TRANSACTION_READ_HEADERS  [dt=1]
t= 914 [st= 143]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=1]
t= 915 [st= 144]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 401 Unauthorized
                            Date: Mon, 09 Oct 2017 15:17:23 GMT
                            Server: Apache/2.4.10 (Ubuntu)
                            WWW-Authenticate: Basic realm="authentication needed"
                            Content-Length: 456
                            Keep-Alive: timeout=5, max=100
                            Connection: Keep-Alive
                            Content-Type: text/html; charset=iso-8859-1
t= 915 [st= 144]     -HTTP_TRANSACTION_READ_HEADERS
t= 915 [st= 144]      URL_REQUEST_DELEGATE  [dt=0]
t= 915 [st= 144]      URL_REQUEST_DELEGATE  [dt=0]
t=3539 [st=2768]      URL_REQUEST_DELEGATE  [dt=0]
t=3539 [st=2768]      HTTP_TRANSACTION_DRAIN_BODY_FOR_AUTH_RESTART  [dt=0]
t=3539 [st=2768]      AUTH_SERVER  [dt=0]
t=3539 [st=2768]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=3539 [st=2768]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                        --> GET / HTTP/1.1
                            Host: localhost
                            Connection: keep-alive
                            Authorization: [22 bytes were stripped]
                            User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3230.0 Safari/537.36
                            Upgrade-Insecure-Requests: 1
                            Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            Accept-Encoding: gzip, deflate, br
                            Accept-Language: en-US,en;q=0.9,hu;q=0.8
t=3539 [st=2768]     -HTTP_TRANSACTION_SEND_REQUEST
t=3539 [st=2768]     +HTTP_TRANSACTION_READ_HEADERS  [dt=2]
t=3539 [st=2768]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=2]
t=3541 [st=2770]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 200 OK
                            Date: Mon, 09 Oct 2017 15:17:25 GMT
                            Server: Apache/2.4.10 (Ubuntu)
                            Last-Modified: Tue, 03 Oct 2017 15:30:40 GMT
                            ETag: "2c39-55aa62c7a2ce8-gzip"
                            Accept-Ranges: bytes
                            Vary: Accept-Encoding
                            Content-Encoding: gzip
                            Content-Length: 3186
                            Keep-Alive: timeout=5, max=99
                            Connection: Keep-Alive
                            Content-Type: text/html
t=3541 [st=2770]     -HTTP_TRANSACTION_READ_HEADERS
t=3541 [st=2770]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=3541 [st=2770]      HTTP_CACHE_WRITE_DATA  [dt=0]
t=3541 [st=2770]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=3542 [st=2771]      URL_REQUEST_DELEGATE  [dt=0]
t=3542 [st=2771]      URL_REQUEST_FILTERS_SET
                      --> filters = "GZIP"
t=3542 [st=2771]   -URL_REQUEST_START_JOB
t=3542 [st=2771]    URL_REQUEST_DELEGATE  [dt=4]
t=3546 [st=2775]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=3546 [st=2775]    HTTP_CACHE_WRITE_DATA  [dt=0]
t=3546 [st=2775]    URL_REQUEST_JOB_BYTES_READ
                    --> byte_count = 3186
t=3546 [st=2775]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                    --> byte_count = 11321
t=3546 [st=2775]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=3546 [st=2775]    HTTP_CACHE_WRITE_DATA  [dt=0]
t=3546 [st=2775] -REQUEST_ALIVE

Similarily cannot reproduce on Chrome 61.0.3163.100 Stable or 62.0.3202.45 Beta either.

A couple of additional questions for the original poster.   Please don't let these distract you from the netlog--that's really going to be the top thing that would help us to figure out what's going on.

*) What indicates to you that the garbage is gzipped, as opposed to compressed in some other fashion?  We've see problems like this coming from Google serving Brotli compressed responses and intermediate middleboxes stripping out the Content-Encoding: br header.

* When you say "If you disable gzipping of the response to the correct HTTP Basic Auth attempt the problem is gone." how did you disable the gzipping?

* Are you behind a firewall?  If so, what brand?  Have you reproduced this from a direction connection without that firewall?

Sorry for not answering earlier but I am trying to setup simple test server to reproduce this issue with a minimal config. Then I will provide netlog and access to the server.

-1. I am not an (complete) idiot. Usually. And most of the time I know what I am doing and testing. :)
0. I don't know yet if it's problem with Chromium or with nginx or with nginx configuration.
1. Nothing indicates that the garbage is gzipped, I can't parse gzip with my eyes. :) On the other hand it's not very probable that it's some other compression method because as far as I know nginx is only using gzip. And the headers seemed to be OK. And curl managed to download the page OK too.
2. gzip off; in nginx.conf in all the right places.
3. No firewall. Direct connection to the servers for me. But other people all around the world saw it too. On two different servers/server OSes and several different Chrome(ium) versions/OSes.

But it's still possible that it's some weird proxy problem in nginx or my nginx configuration hits some undocumented case. I am using multi-level proxying there. That's why I am trying to set up a minimal test case that still reproduces the problem.

Thank you for your support so far.

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

Thanks for the update. I'll keep the needs-feedback label until you are ready.

@ g.qed.ai : Could you please update on comment #9.

Thank You!

g.qed.ai: I'm closing this for lack of activity. Please file a new bug if you can provide the information requested.