After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 680029 - Responses from soup cache always have zero content-legth and null content type
Responses from soup cache always have zero content-legth and null content type
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2012-07-16 16:23 UTC by Carlos Garcia Campos
Modified: 2012-07-16 17:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add Content-Length to the response headers before sending the response (997 bytes, patch)
2012-07-16 16:25 UTC, Carlos Garcia Campos
reviewed Details | Review
Save the sniffed mime type in the cache too (2.89 KB, patch)
2012-07-16 16:26 UTC, Carlos Garcia Campos
committed Details | Review
soup_message_headers_get_content_length: recheck encoding (1.16 KB, patch)
2012-07-16 16:59 UTC, Dan Winship
committed Details | Review

Description Carlos Garcia Campos 2012-07-16 16:23:49 UTC
This breaks WebKit2 unit tests when disk cache is enabled, because it assumes valid content-length and content-type from the cache.
Comment 1 Carlos Garcia Campos 2012-07-16 16:25:56 UTC
Created attachment 218925 [details] [review]
Add Content-Length to the response headers before sending the response
Comment 2 Carlos Garcia Campos 2012-07-16 16:26:22 UTC
Created attachment 218927 [details] [review]
Save the sniffed mime type in the cache too
Comment 3 Dan Winship 2012-07-16 16:31:28 UTC
Comment on attachment 218925 [details] [review]
Add Content-Length to the response headers before sending the response

>+	/* Content-Length */
>+	soup_message_headers_set_content_length (msg->response_headers, entry->length);

Hm... So WK requires that anything retrieved from cache has a known Content-Length, even if we didn't know the Content-Length when it was originally downloaded? (eg, chunked or read-to-eof encoding)?
Comment 4 Dan Winship 2012-07-16 16:31:59 UTC
Comment on attachment 218927 [details] [review]
Save the sniffed mime type in the cache too

ok
Comment 5 Carlos Garcia Campos 2012-07-16 16:39:04 UTC
(In reply to comment #3)
> (From update of attachment 218925 [details] [review])
> >+	/* Content-Length */
> >+	soup_message_headers_set_content_length (msg->response_headers, entry->length);
> 
> Hm... So WK requires that anything retrieved from cache has a known
> Content-Length, even if we didn't know the Content-Length when it was
> originally downloaded? (eg, chunked or read-to-eof encoding)?

No, it's just the resources unit tests, that assumes content-length is set in the headers. We always check the content length is the same than the resource data size. It works the first time, but fails the second time because the resources is loaded from the cache.
Comment 6 Dan Winship 2012-07-16 16:47:01 UTC
If the original response had a Content-Length header, then that should be saved in the cache with the rest of the headers, and then copied back in to the cache response with the rest of the headers, and then read back by soup_request_http_get_content_length()... so this code shouldn't be needed if everything is working correctly.
Comment 7 Carlos Garcia Campos 2012-07-16 16:55:16 UTC
I think the content length header is always reset by soup cache, because copy_end_to_end_headers removes the tansfer encoding header. So even if the original request had content lenght it's not saved in the cache
Comment 8 Dan Winship 2012-07-16 16:59:59 UTC
Created attachment 218935 [details] [review]
soup_message_headers_get_content_length: recheck encoding

Use soup_message_headers_get_encoding() rather than looking at
hdrs->encoding directly, so that it gets recomputed if it's stale (eg,
from another header having been removed).

====

Try this...
Comment 9 Carlos Garcia Campos 2012-07-16 17:02:59 UTC
It works!
Comment 10 Carlos Garcia Campos 2012-07-16 17:08:46 UTC
Pushed both patches to git master.