Bug 60415 - [GTK] Missing response for HTTP requests in Inspector when using the Soup cache
Summary: [GTK] Missing response for HTTP requests in Inspector when using the Soup cache
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-06 16:08 PDT by Xan Lopez
Modified: 2012-10-30 06:33 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2011-05-06 16:08:15 PDT
Try to load planet.gnome.org with epiphany+soup cache enabled. Some of the resource requests will lack a response according to the Inspector. The page is still loaded, so I guess we are calling didReceiveData but not didReceiveResponse for some reason. This might why the page takes a long time to load, WebKit might be timing out the requests. As an experiment try to disable the soup cache and load+reload planet gnome. At least in my machine it's *a lot* faster *without* the cache.
Comment 1 Sergio Villar Senin 2011-05-08 23:36:56 PDT
(In reply to comment #0)
> Try to load planet.gnome.org with epiphany+soup cache enabled. Some of the resource requests will lack a response according to the Inspector. The page is still loaded, so I guess we are calling didReceiveData but not didReceiveResponse for some reason. This might why the page takes a long time to load, WebKit might be timing out the requests. As an experiment try to disable the soup cache and load+reload planet gnome. At least in my machine it's *a lot* faster *without* the cache.

I'm almost sure that we are not calling didReceiveData without a previous didReceiveResponse because we added some asserts to check that some months ago and I never got a hit on them. I noticed issues with planet.gnome.org but everytime I checked, they were caused by unreachable resources (in particular some icons). This means that Chrome for example was also taking a lot of time to load the page (until a timeout was triggered).

But if you say that disabling the cache improves the situation then it could be something else, will take a look.
Comment 2 Sergio Villar Senin 2011-05-09 09:49:05 PDT
(In reply to comment #1)
> (In reply to comment #0)
> But if you say that disabling the cache improves the situation then it could be something else, will take a look.

I think I've just found what happens here. The problem is that I forgot to cache the status code of the responses, and thus, I'm not resetting it in the responses generated by the cache. Will file a bug in libsoup and set a dependency.

BTW I have also realized that we are caching all the headers and some of them (the so called hop-by-hop headers) should not as are are meaningful only for a single transport-level connection. Will file another bug in libsoup for this
Comment 3 Sergio Villar Senin 2011-05-11 06:50:58 PDT
https://bugzilla.gnome.org/show_bug.cgi?id=649965
Comment 4 Dominik Röttsches (drott) 2012-10-30 06:33:30 PDT
Upstream soup bug fixed.