You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2021/03/15 18:00:13 UTC

[Bug 65188] New: Chrome sec-ch-ua header problem

https://bz.apache.org/bugzilla/show_bug.cgi?id=65188

            Bug ID: 65188
           Summary: Chrome sec-ch-ua header problem
           Product: Apache httpd-2
           Version: 2.4.41
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: All
          Assignee: bugs@httpd.apache.org
          Reporter: erik@vanlinsteeict.nl
  Target Milestone: ---

I have an upstream Apache2 webserver version 2.4.41 on Ubuntu 20.04. Downstream
is an NGinx reverse proxy. NGinx does TLS too.

Recently, I found that I could no longer reach sites using Chrome. Firefox
worked fine. It turns out that if I have NGinx remove the sec-ch-ua header that
Chrome sends, everything works again.

This is the header field that Chrome sends:

sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"

Clearly, it does not conform to the standard, but I understand that was done on
purpose.

There are no errors in the Apache log. In fact, a request does not even appear
to get far enough for the dumpio module to log it.

What I can tell from a packet trace is that NGinx answers the client Hello and
then sets up a TCP connection to Apache, on which it writes the (plain) HTTP
request. Apache accepts the connection attempt, but then resets it immediately.

So to summarise:
- NGinx receives and answers the TLS Client Hello.
- NGinx connects to Apache and sends the HTTP request.
- Apache accepts the connection and receives the request.
- Apache closes the connection, without a response or log message.

When NGinx removes the entire sec-ch-ua header field, Apache does respond to
the request.
If I let Nginx add the header field as Chrome sends it, Firefox and other
browsers can't reach the site either.

So clearly, the header field is the problem.

I don't know exactly which Chrome update broke Apache2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org