In the Resources panel, the resource data (HTTP response data) is not always displayed. See Bug 28812, comment 6. A case where this occurs is when loading the URL: http://www.lumacentral.com/CocaCola/index.html One of the resources, named "execBatch" has an HTTP response which is not displayed. Here is a replay of the individual resource request in curl. As you can see, there actually is some content coming from the request. $ curl -H "Content-Type: application/xml" -d "<lw2p-requests><lw2p-request action='getCurrentPortal'/></lw2p-requests>" -v http://www.lumacentral.com/CocaCola/w2p/execBatch - About to connect() to www.lumacentral.com port 80 (#0) - Trying 194.78.34.228... connected - Connected to www.lumacentral.com (194.78.34.228) port 80 (#0) > POST /CocaCola/w2p/execBatch HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Host: www.lumacentral.com > Accept: */* > Content-Type: application/xml > Content-Length: 72 > < HTTP/1.1 200 OK < Date: Mon, 05 Oct 2009 15:36:37 GMT < Cache-Control: no-cache < Set-Cookie: JSESSIONID=49ACA557EE891188BDB2B334CF2B4B7E; Path=/CocaCola < mime-type: application/xml < Transfer-Encoding: chunked < Content-Type: text/plain < <?xml version="1.0" encoding="UTF-8"?> - Connection #0 to host www.lumacentral.com left intact - Closing connection #0 <lw2p-replies><lw2p-reply action="getCurrentPortal"><portal description="" id="52" name="CocaCola" version="10"/></lw2p-reply></lw2p-replies>
Note that Bug 30079 concerns the same base URL for it's problem. In talking to Jeroen Bensch, the originator of the problem requests, seems like 30079 may be a root cause here. May want to investigate that one first.
Jeroen, I'm wondering if those execBatch XHR calls are happening in the .swf movie itself. I poked around the resources available from the original site, and didn't see any references to the execBatch urls. This may explain why the resource content doesn't show up - there is a separate path to obtain the resource than other paths the browser goes through to get files. Not that it's necessarily right, but it would explain a bit. In fact, I just poked on the resource selectors, and noticed these execBatch URLs are showing up under "Other". As is the .swf file itself, presumably loaded through an "embed" or "object" element (or whatever). It's interesting that everything seems to be available for these resources, except the actual content. Maybe it won't take much to hook that up. Will need to investigate the plugin goop, I guess.
The Web Inspector does not know how to render "Other" content right now. We might have the data, but we don't attempt to show it. We need to know what type of data to pick the view that shows it. We try to do this based on the category the engine tells us, images, etc. I think we also look at mime type.
(In reply to comment #3) > The Web Inspector does not know how to render "Other" content right now. We > might have the data, but we don't attempt to show it. > > We need to know what type of data to pick the view that shows it. We try to do > this based on the category the engine tells us, images, etc. I think we also > look at mime type. (In reply to comment #3) > The Web Inspector does not know how to render "Other" content right now. We > might have the data, but we don't attempt to show it. > > We need to know what type of data to pick the view that shows it. We try to do > this based on the category the engine tells us, images, etc. I think we also > look at mime type. Sounds like we can DUP this for the existing Bug 14259
I'm following your reasoning and discussion here, but I don't know how I could help. Thanks though for looking into it. I thought the reason why it wasn't shown is that because everything in that .swf file comes back as xml (with appropriate header) and you just discarded that when trying to show the response payload.
Created attachment 98342 [details] Patch
Comment on attachment 98342 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=98342&action=review > Source/WebCore/inspector/NetworkResourcesData.cpp:182 > + m_contentSize -= resourceData->purgeContent(); This is clearly worth a test. > Source/WebCore/inspector/NetworkResourcesData.h:68 > + bool hasData() const { return m_dataBuffer; } Make these private + a friend of the NetworkResourceData.
Created attachment 98792 [details] Patch (for gtk bot)
Comment on attachment 98792 [details] Patch (for gtk bot) Attachment 98792 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/8952335
Created attachment 98896 [details] Patch (for gtk bot)
Created attachment 99073 [details] Patch
Created attachment 99086 [details] Patch with build fixes
Comment on attachment 99086 [details] Patch with build fixes View in context: https://bugs.webkit.org/attachment.cgi?id=99086&action=review > Source/WebCore/WebCore.exp.in:1303 > +__ZNK7WebCore8Document4pageEv @dglazkov: are we exporting webcore symbols both for webkit and for internals using the same file on mac?
(In reply to comment #13) > (From update of attachment 99086 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=99086&action=review > > > Source/WebCore/WebCore.exp.in:1303 > > +__ZNK7WebCore8Document4pageEv > > @dglazkov: are we exporting webcore symbols both for webkit and for internals using the same file on mac? Yep.
Comment on attachment 99086 [details] Patch with build fixes Rejecting attachment 99086 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=ec2-cq-02', '--port..." exit_code: 2 Last 500 characters of output: re/loader/FormState.o Source/WebCore/loader/DocumentThreadableLoader.cpp: In member function 'virtual void WebCore::DocumentThreadableLoader::didReceiveData(WebCore::SubresourceLoader*, const char*, int)': Source/WebCore/loader/DocumentThreadableLoader.cpp:232: error: 'didReceiveContentLength' is not a member of 'WebCore::InspectorInstrumentation' make: *** [out/Debug/obj.target/webcore_remaining/Source/WebCore/loader/DocumentThreadableLoader.o] Error 1 make: *** Waiting for unfinished jobs.... Full output: http://queues.webkit.org/results/8982506
Committed r90373: <http://trac.webkit.org/changeset/90373>
Rolled out: http://trac.webkit.org/changeset/90373 https://bugs.webkit.org/show_bug.cgi?id=63917
Committed r90389: <http://trac.webkit.org/changeset/90389>