search

cloudtrends / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
1 stars 1 forks source link

HandleDownloadResponse not called for all downloads #156

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

Enter 1 of the following 2 URLs into CefClient:
1. 
http://www.microsoft.com/investor/Downloads/Earnings%20and%20Financials/Earnings
%20Releases/PressRelease/FY11/Q1/Q1-FY11Slides.pptx
2. http://crypto.stanford.edu/DRM2002/darknet5.doc

What is the expected output? What do you see instead?

I expect the URLs to trigger a download, but HandleDownloadResponse is never 
called.

This is not the case for all downloads.  For example, the following URL results 
in the expected behavior:
http://digitalcommons.unl.edu/cgi/viewcontent.cgi?filename=1&article=1003&contex
t=ir_information&type=additional&rct=j

Could some header be responsible for this behavior?

What version of the product are you using? On what operating system?
CEF r149, Win XP

Please provide any additional information below.

Original issue reported on code.google.com by mikeyk...@gmail.com on 15 Dec 2010 at 12:54

GoogleCodeExporter commented 9 years ago 
When loading this page in CefClient, 
http://code.google.com/p/chromiumembedded/issues/detail?id=156 , a JavaScript 
file "kibbles-1.3.2.comp.js" is downloaded.  This does not seem to be desired 
behavior

Original comment by mikeyk...@gmail.com on 15 Dec 2010 at 12:58

GoogleCodeExporter commented 9 years ago 
The implementation is a bit flaky because we have to parse HTTP headers to 
identify download requests. See IsContentDispositionAttachment in 
browser_webkit_glue.cc and related usage. Patches to improve this functionality 
are welcome.

Original comment by magreenb...@gmail.com on 16 Dec 2010 at 6:58

GoogleCodeExporter commented 9 years ago 
CEF currently initiates a download if and only if the Content-Disposition 
header is "attachment".

The attached patch modifies CEF to follow the same logic as Chrome:
1. Block potential downloads if the request isn't at the frame or subframe 
level (e.g. don't download an embedded js file no matter what the headers 
indicate)
2. If Content-Disposition is "attachment" or unrecognized, download the file.
3. If the mime type isn't handled by the browser or a registered plugin, 
download the file.

I structured the code based on what I saw in Chrome.  Let me know if you think 
the information flow can be improved.  I'd be happy to make any changes to the 
proposed patch.  Thanks!

Original comment by mikeyk...@gmail.com on 28 Dec 2010 at 5:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks, committed as revision 155 with some minor style changes (mostly line 
wrapping problems).

Original comment by magreenb...@gmail.com on 6 Jan 2011 at 7:27