GNOME Bugzilla – Bug 641022
SoupRequestData does not return decoded contents for data URLs
Last modified: 2011-01-31 19:38:29 UTC
SoupRequestData is decoding data URLs but it's not returning the decoded data but the original one.
Created attachment 179709 [details] [review] Patch
Created attachment 179722 [details] [review] soup-request-data: fix content-type decoding in non-base64 case the original code made sense in webkit where it was using an in-place URI-decoding method, but here, it's weird to assign the encoded value to priv->content_type and then overwrite it. here's a counterpatch. Does this break some WebKit test, or did you just notice the memory leak?
Created attachment 179737 [details] [review] soup-request-data: fix content-type decoding in non-base64 case. v2 (In reply to comment #2) > Created an attachment (id=179722) [details] [review] > soup-request-data: fix content-type decoding in non-base64 case > > the original code made sense in webkit where it was using an in-place > URI-decoding method, but here, it's weird to assign the encoded value > to priv->content_type and then overwrite it. here's a counterpatch. Fair enough, but you're omitting the second part of the patch, the other soup_uri_decode that is not assigned to anything. Here you have my counter-counter-patch :) > Does this break some WebKit test, or did you just notice the memory > leak? Yeah, basically most of tests with data URLs (after applying your webkitgtk+ patches) were not working, then I reviewed the libsoup code and detected the leak (and the bug).
Comment on attachment 179737 [details] [review] soup-request-data: fix content-type decoding in non-base64 case. v2 > Fair enough, but you're omitting the second part of the patch doh. Hence my confusion, since I couldn't see any webkit tests that had uri-encoded content-types, so just the first part shouldn't have mattered to that. looks good. thanks.
Committed ea5b7457