This needs to be confirmed.

In order for test to test this, we would need a test page created by dev. 

anything I can do to help this get confirmed?

Please take a look. Is this iOS-only? 

yes, iOS only. multiple versions if iOS (e.g. 6, X). other platforms (e.g. Android, desktop) and browsers (e.g. Safari on iOS), demonstrate normal behavior, it's just Chrome on iOS.

Indeed, the GET parameter is kept during the favicon request (the favicon.ico one).
agfung@: Can you confirm that this only happens for the favicon.ico file at the root of the WebSite?

+eugenebut@ as the creation of the favicon.ico url is happening in web/.

The GET request for the favicon.ico is always from the root.

However, moving the HTML page away from the root to a sub-path can still trigger the favicon request.

i.e. placing the HTML above at /index.html, loading the page and clicking the submit button, I get this sequence:

"GET / HTTP/1.1"
"GET /favicon.ico HTTP/1.1"
"POST /bar/?q1 HTTP/1.1"
"GET /favicon.ico?q1 HTTP/1.1"

then moving the index.html to the path /foobar, using the same browser, I get this sequence:

"GET /foobar/ HTTP/1.1"
"POST /foobar/bar/?q1 HTTP/1.1"

i.e. no additional favicon request; presumably the browser knows that it has a recent favicon.ico for /favicon.ico?q1. however, changing the query parameter in the HTML from "q1" to "q2", and leaving it at /foobar/index.html, I can then get this sequence:

"GET /foobar/ HTTP/1.1"
"POST /foobar/bar/?q2 HTTP/1.1"
"GET /favicon.ico?q2 HTTP/1.1"

i.e. browser seems to think that any unique combination of hostname and query parameter means it should check for a different /favicon.ico

As noted earlier, this behaviour of making the favicon.ico request with a query parameter, seems unique to Chrome on iOS.  Safari on iOS and Chrome on desktop and Android don't do this.

I suppose technically it's valid to behave this way, but I don't understand what's trying to be accomplished, since the resource /favicon.ico shouldn't differ based on query parameter values.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b67d11ca0a63a3437d6ac95cb34353d1283d8c5a

commit b67d11ca0a63a3437d6ac95cb34353d1283d8c5a
Author: Gauthier Ambard <gambard@chromium.org>
Date: Tue Jan 30 16:18:28 2018

Strip the query part when fetching the favicon.ico

This CL changes the creation of the URL used to get the favicon at the
root of the WebSite (www.website.com/favicon.ico), which is used to get
a favicon if non is provided in the html of the page.
It strips the query part of the URL, to avoid re-downloading a new
favicon everytime the query part of the URL changes.

Bug:  804077 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I1d6224af357065ab749031ca3533d5f5a5d092ff
Reviewed-on: https://chromium-review.googlesource.com/889739
Commit-Queue: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532900}
[modify] https://crrev.com/b67d11ca0a63a3437d6ac95cb34353d1283d8c5a/ios/web/web_state/favicon_callbacks_inttest.mm
[modify] https://crrev.com/b67d11ca0a63a3437d6ac95cb34353d1283d8c5a/ios/web/web_state/ui/crw_web_controller.mm

Thanks for the explanations. I have fixed it for M66.
I have also fixed it for ref parameters (i.e. before /foobar/bar#h1 would trigger a GET /favicon.ico#h1).

I am marking it as fixed.