Bug 60415
| Summary: | [GTK] Missing response for HTTP requests in Inspector when using the Soup cache | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Xan Lopez <xan.lopez> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | d-r, mrobinson, svillar |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Xan Lopez
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Sergio Villar Senin
(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.
Sergio Villar Senin
(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
Sergio Villar Senin
https://bugzilla.gnome.org/show_bug.cgi?id=649965
Dominik Röttsches (drott)
Upstream soup bug fixed.