[Webkit-unassigned] [Bug 38665] [chromium] Update chromium port to send/receive cached metadata

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 10 17:36:42 PDT 2010


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





--- Comment #14 from Tony Gentilcore <tonyg at chromium.org>  2010-05-10 17:36:41 PST ---
(In reply to comment #12)
> (From update of attachment 55596 [details])
> WebKit/chromium/src/ResourceHandle.cpp:181
>  +          CRASH();
> This seems a bit harsh.  Is this what other code in this file does?

Yeah, didReceiveResponse, didReceiveData, didFinishLoading, all have similar statements that ensure the state is expected. I'm fine with removing it if it is less important here because things will work even if the cached metadata is never received.

> 
> WebCore/platform/chromium/ChromiumBridge.h:76
>  +          static void cacheMetadata(const KURL& url, long long responseTime, const Vector<char>&);
> Does a pair of URL+responseTime uniquely determine an HTTP response?  What if the clock gets reset?  This seems like a proxy for a response ID.  Why not create a response ID?

Response time is what is required by the HTTP Cache API that fishd and rvargas put together here: http://codereview.chromium.org/600167/diff/9001/9008

I don't think clock reset is a factor unless it was reset in the very slim time between the load of the resource and the generation of metadata. And even in that case, we'd just miss an opportunity to cache the metadata. Once the metadata is stored in the cache, the response time doesn't matter for future loads.

-- 
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