Bug 245625 – [SOUP] Spammed by 0-byte downloads on imgur.com

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

Reproducer: visit https://imgur.com/

imgur will immediately download three 0-byte files: sync, pixelSync, and ingest. This does not happen in Firefox. All three files are downloaded again for every reload or navigation on imgur.com.

[Karl Dubost]

Michael, 

I do not see the 0-byte downloads as you mentioned. 
Is this still happening?
Do you have more details about your setup?

[Michael Catanzaro]

(In reply to Karl Dubost from comment #1)
> Michael, 
> 
> I do not see the 0-byte downloads as you mentioned. 

You need to use WebKitGTK or WPE WebKit, which use the libsoup network backend.

> Is this still happening?

Yes.

> Do you have more details about your setup?

I use Epiphany Tech Preview from https://webkit.org/downloads/

[Carlos Garcia Campos]

I can't reproduce it either with epiphany.

[Michael Catanzaro]

Started looking into this. Epiphany's decide-policy callback uses webkit_response_policy_decision_is_mime_type_supported() and downloads anything not supported by WebKit, which is surely correct... at least, it seems like what we intend for browsers to do with the response policy decision; it doesn't make sense to have webkit_response_policy_decision_is_mime_type_supported() otherwise. When this happens, MIMETypeRegistry::canShowMIMEType returns "application/octet-stream", which is of course not supported.

I'm not sure what to do next. I don't think browsers should require special code to skip 0-byte resources, and I also don't we should skip the policy decision for 0-byte resources. I'm not sure if it's safe for WebKit to block them; they're almost certainly tracking pixels, which users don't like, but I wouldn't be surprised if some websites break if we don't let them load.

I wonder why Carlos Garcia is not able to reproduce with Epiphany. I actually wind up with 6-9 new downloads for each visit to imgur.com, since it repeats the same three 0-byte downloads again and again.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> I wonder why Carlos Garcia is not able to reproduce with Epiphany. I
> actually wind up with 6-9 new downloads for each visit to imgur.com, since
> it repeats the same three 0-byte downloads again and again.

If you visit https://order.noodles.com/ do you see the 0-byte asyncPixelSync that gets downloaded?

Although unlikely, it's possible this could differ if you're using a different version of shared-mime-info.

[Carlos Garcia Campos]

I can reproduce with order.noodles.com. This needs 3 fixes in 3 different places:

1.- libsoup: sniffer is not run in http/2 for resources with no content. In http/1 the sniffer sets the content type as text/plain, we should do the same for http/2. This would fix the bug, because can show mime type will return true.

2.- Epiphany: should never try to download subresources that can't be handled by the web view.

3.- WebKit: should not ignore subresources with no content. After fixing libsoup this can only happen when the sniffer is disabled.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/5489

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #6)
> I can reproduce with order.noodles.com. This needs 3 fixes in 3 different
> places:
> 
> 1.- libsoup: sniffer is not run in http/2 for resources with no content. In
> http/1 the sniffer sets the content type as text/plain, we should do the
> same for http/2. This would fix the bug, because can show mime type will
> return true.

https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/325

> 2.- Epiphany: should never try to download subresources that can't be
> handled by the web view.

https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1205

> 3.- WebKit: should not ignore subresources with no content. After fixing
> libsoup this can only happen when the sniffer is disabled.

https://github.com/WebKit/WebKit/pull/5489

[EWS]

Committed 255721@main (16644424b977): <https://commits.webkit.org/255721@main>

Reviewed commits have been landed. Closing PR #5489 and removing active labels.