Bug 75242

Summary: [WK2] add new APIs on WKURLResponse for getting content type and expected content length
Product: WebKit Reporter: Keunsoon Lee <keunsoon.lee>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Enhancement CC: andersca, cgarcia, gyuyoung.kim, gyuyoung.kim, ibchang, leandro, lucas.de.marchi, mrobinson, rakuco, sam, t.morawski, uvv.mail
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
new APIs on WKURLResponse and their implementaion on WebURLResponse
none
removed a extra line none

Keunsoon Lee
Reported 2011-12-27 00:31:58 PST
Hi, This is a suggestion for WK2 API, not a bug. I think it would be useful to add new APIs to obtain content type and expected content length on WKURLResponse. Here are some specific use cases. For content type; application can use this to determine policy when receiving decidePolicyForResponse for WKPagePolicyClient. For example, application can extract a MIMEType from WKURLResponseRef, and decide to download for some specific MIME type instead of calling WKFramePolicyListenerUse(). For content length; application can use this to draw progress bar when getting callbacks for WKContextDownloadClient. Application cannot know the downloaded percentage unless it obtains expected content length. I think these APIs have port-widely common usage, so suggested them to add WK2 API. By the way, to activate these APIs, all port should add encode/decode for ResourceResponse's mimeType() and expectedContentLength() on each WebCoreArgumentCoderXXX. If you think this patch is acceptable, I'll take care of it. Thank you.
Attachments
new APIs on WKURLResponse and their implementaion on WebURLResponse (3.46 KB, patch)
2011-12-27 01:51 PST, Keunsoon Lee 		no flags
DetailsFormatted DiffDiff
removed a extra line (3.46 KB, patch)
2011-12-27 04:45 PST, Keunsoon Lee 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Keunsoon Lee
Comment 1 2011-12-27 01:51:31 PST
Created attachment 120574 [details] new APIs on WKURLResponse and their implementaion on WebURLResponse Uploaded patch only including API implementation. I'll add encode/decode and test code if it is acceptable.
Raphael Kubo da Costa (:rakuco)
Comment 2 2011-12-27 04:13:41 PST
Comment on attachment 120574 [details] new APIs on WKURLResponse and their implementaion on WebURLResponse View in context: https://bugs.webkit.org/attachment.cgi?id=120574&action=review Since these changes are not port-specific, you need to CC non-EFL people to get it reviewed. I suggest using Tools/Scripts/webkit-patch suggest-reviewers. > Source/WebKit2/Shared/API/c/WKURLResponse.h:41 > + Nitpick: extra empty line.
Keunsoon Lee
Comment 3 2011-12-27 04:45:04 PST
(In reply to comment #2) > (From update of attachment 120574 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=120574&action=review > > Since these changes are not port-specific, you need to CC non-EFL people to get it reviewed. I suggest using Tools/Scripts/webkit-patch suggest-reviewers. > > > Source/WebKit2/Shared/API/c/WKURLResponse.h:41 > > + > > Nitpick: extra empty line. Thank you for your comment! I'll fix it on a new patch.
Keunsoon Lee
Comment 4 2011-12-27 04:45:54 PST
Created attachment 120577 [details] removed a extra line
Sam Weinig
Comment 5 2011-12-27 08:20:34 PST
Comment on attachment 120577 [details] removed a extra line I don't think there is a compelling reason to add this API right now, as the primary way of accessing response data would be an accessor for a platform specific response type (eg. CFURLResponseRef, etc.) Can you explain in greater detail why you think these should be added?
Keunsoon Lee
Comment 6 2011-12-27 22:54:28 PST
(In reply to comment #5) > (From update of attachment 120577 [details]) > I don't think there is a compelling reason to add this API right now, as the primary way of accessing response data would be an accessor for a platform specific response type (eg. CFURLResponseRef, etc.) Can you explain in greater detail why you think these should be added? Thank you for your review! You're right, client application can get those information from each platform specific response type. But they should know about each response type and related APIs on each header file. With this patch, client does not need to know the specific information, but only common API on common header. And I think the suggested APIs are suitable for WebKit2 API layer's spirit besides the client's convenience. I guess WebKit2 API layer is trying to unify communication way to client. Because almost all APIs are not platform specific except for helpless small part. (Please let me know if I am wrong.) If so, this patch can help it. Content type and expected content length are fields on HTTP specification, and WebCore::ResourceResponseBase already has them. I checked following ports set the values on their specific WebCore::ResourceResponse through WebCore::ResponseResponseBase's set function; blackberry, curl, soup and win. So, they are not platform specific values. I cannot find a reason why non-platform specific values are exposed through platform-specific APIs. It is inconvenient for client as well. PS, this patch does not cause any crash even if any platform does not implement it, but returns nothing. I checked gtk and qt ports already have implemented it on their WebCoreArgumentCodersXXX regardless of this patch. So, I think the implementation is not a burden. Thank you again.
Keunsoon Lee
Comment 7 2012-04-24 05:17:39 PDT
This patch will be handled on 70231. Closed to clear up. *** This bug has been marked as a duplicate of bug 70231 ***
Note You need to log in before you can comment on or make changes to this bug.