NEW 31019
Get rid of lengthReceived parameter in ResourceHandleClient::didReceiveData 
https://bugs.webkit.org/show_bug.cgi?id=31019
Summary Get rid of lengthReceived parameter in ResourceHandleClient::didReceiveData
Yury Semikhatsky
Reported 2009-11-02 10:35:58 PST
As fat as I can see this parameter has always the same value as dataLength. Moreover, at some point it gets passed to InspectorController::didReceiveContentLength where it is treated as dataLength(i.e. length of the just received chunk of data). Here is the example call stack where InspectorController::didReceiveContentLength is called with. Probably InspectorController::didReceiveContentLength should be renamed? > chrome.dll!WebCore::InspectorController::didReceiveContentLength(WebCore::DocumentLoader * __formal=0x01412200, unsigned long identifier=48, int lengthReceived=5191) Line 978 C++ chrome.dll!WebCore::ResourceLoadNotifier::dispatchDidReceiveContentLength(WebCore::DocumentLoader * loader=0x01412200, unsigned long identifier=48, int length=5191) Line 151 C++ chrome.dll!WebCore::ResourceLoadNotifier::didReceiveData(WebCore::ResourceLoader * loader=0x0433b200, const char * data=0x00e70000, int length=5191, int lengthReceived=5191) Line 83 C++ chrome.dll!WebCore::ResourceLoader::didReceiveData(const char * data=0x00e70000, int length=5191, __int64 lengthReceived=5191, bool allAtOnce=false) Line 254 C++ chrome.dll!WebCore::MainResourceLoader::didReceiveData(const char * data=0x00e70000, int length=5191, __int64 lengthReceived=5191, bool allAtOnce=false) Line 375 C++ chrome.dll!WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle * __formal=0x0145b560, const char * data=0x00e70000, int length=5191, int lengthReceived=5191) Line 398 + 0x1f bytes C++ ...
Attachments
Add attachment proposed patch, testcase, etc.
Timothy Hatcher
Comment 1 2009-11-02 10:51:54 PST
Maybe this is why we show uncompressed size instead of compressed (bug 19793). Do the numbers differ if gzip server compression is used?
Yury Semikhatsky
Comment 2 2009-11-02 11:39:25 PST
I tried setting a breakpoint in ResourceLoader::didReceiveData with condition length!=lengthReceived. It's never hit when loading apache.org (In reply to comment #1) > Maybe this is why we show uncompressed size instead of compressed (bug 19793). > Do the numbers differ if gzip server compression is used?
Yury Semikhatsky
Comment 3 2009-11-02 11:41:20 PST
I tried this in Safari on Mac OS X 10.5.8 (9L31a) and ToT WebKit built. (In reply to comment #2) > I tried setting a breakpoint in ResourceLoader::didReceiveData with condition > length!=lengthReceived. It's never hit when loading apache.org > > (In reply to comment #1) > > Maybe this is why we show uncompressed size instead of compressed (bug 19793). > > Do the numbers differ if gzip server compression is used?
Timothy Hatcher
Comment 4 2009-11-02 12:23:14 PST
OK, I guess it is fine to remove.
Alexey Proskuryakov
Comment 5 2009-11-02 19:19:38 PST
Yes, this parameter is supposed to carry original encoded length of the chunk. If it doesn't, that's probably an NSURLConnection bug. Your stack trace is from Chrome, and you also said that this fails on Mac. We should file a bug against NSURLConnection then. Does ResourceHandleCFNet work?
Note You need to log in before you can comment on or make changes to this bug.