[Webkit-unassigned] [Bug 75242] [WK2] add new APIs on WKURLResponse for getting content type and expected content length

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Dec 27 22:54:29 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=75242





--- Comment #6 from Keunsoon Lee <keunsoon.lee at samsung.com>  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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list