[Webkit-unassigned] [Bug 191858] [GTK] Unexpected User-Agent on redirect

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191858

--- Comment #11 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to youenn fablet from comment #10)
> (In reply to Carlos Garcia Campos from comment #8)
> > (In reply to youenn fablet from comment #6)
> > > Comment on attachment 407598 [details]
> > > Patch
> > > 
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=407598&action=review
> > > 
> > > > Source/WebKit/ChangeLog:9
> > > > +        request when needsSiteSpecificQuirks setting is enabled.
> > > 
> > > It seems tests are missing here. Can we write some?
> > 
> > It's not easy to test I'm afraid. The user agent changes depending on the
> > site, only when site specific quirks setting is enabled. In tests the host
> > is always localhost. We would need a way to set quirks only used for testing
> > for localhost (and not for 127.0.0.1, for example).
> 
> Seems fine.
> We can also think of using API tests as well.

Even more complicated, in the case of layout tests we have the internals api that we can use to add fake quirks or something like that, but that's more complicated from api tests.

> Quirks are currently based on URL, maybe we can add schemes/port specific
> handling as part of testing.

Well we receive the URL but end up using the hostname to determine the website, so using localhost/127.0.0.1 would work.

> > 
> > > Also, it seems the patch adds a generic boolean but setting the user agent
> > > value is platform specific.
> > 
> > Because the boolean is not specific to the user agent, it's the site
> > specific quirks setting, but it's true it's currently used only by GTK port
> > to set the user agent.
> > 
> > > Currently, the work is mostly done in WebProcess with platform agnostic
> > > code, computation of the user agent value being done by WebPage.
> > 
> > There's WebPage::platformUserAgent() that right now it's only implemented by
> > iOS and Playstation ports. In the case of the iOS port, the change in the
> > user agent doesn't really depend on the URL, but I think playstation also
> > needs to be fixed, moving the user agent quirks to the network process. 
> > 
> > > How is the computation of this value supposed to work in NetworkProcess?
> > 
> > We can't just use a fixed user agent for all websites like major browsers
> > do, because we get messages of unsupported browser, or features disabled, or
> > things simply don't work. So, we need to pretend to be other browsers in
> > some cases depending on the website. That's what we do in
> > WebPage::platformUserAgent(). The problem is that after a redirection, we
> > copy the user agent from the previous request, but the redirected URL might
> > require a different user agent to work. You can see an¡ example of how this
> > can break things in https://bugs.webkit.org/show_bug.cgi?id=215845#c3. So,
> > in case of redirections we need to apply the user agent quirks again, but we
> > are in the network process now. So, this patch moves the user agent quirks
> > to the network process ensuring they are always applied, for the initial
> > request, for downloads, and for the new request after a redirection.
> 
> Which requests are triggering the issue?

The request started after a redirection, because we copy the user agent from the previous request. We need to apply the quirks on the redirected url again. See https://bugs.webkit.org/show_bug.cgi?id=215845#c3.

> Navigation loads should probably be fine since WebProcess is dealing with
> this issue properly.

Right.

> That would leave sub resources and downloads.
> Is the main issue downloads?

The quirks are applied fine in the web process for subresources as well, frame loader asks the client that ends up calling WebPage::platformUserAgent().

Downloads started by the web proccess when a load is converted to a download are not a problem either, the quirks are applied correctly. Downloads started by the web process pool don't get the quirks applied.

I thought it could be even more confusing to apply the quirks both in the web and network processes depending on the request. Also, since we don't know if there will be a redirect, we always have to send the needs quirks setting to the network process for every request.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200901/98e70182/attachment-0001.htm>