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.
Michael, I do not see the 0-byte downloads as you mentioned. Is this still happening? Do you have more details about your setup?
(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/
I can't reproduce it either with epiphany.
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.
(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.
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.
Pull request: https://github.com/WebKit/WebKit/pull/5489
(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
Committed 255721@main (16644424b977): <https://commits.webkit.org/255721@main> Reviewed commits have been landed. Closing PR #5489 and removing active labels.