Am Mittwoch, 5. Januar 2011, 22:05:49 schrieb Dawit Alemayehu: > > On 2011-01-05 11:11:06, Andrea Diamantini wrote: > > > trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp, line 98 > > > <http://svn.reviewboard.kde.org/r/6183/diff/4/?file=43503#file43503l > > > ine98> > > > > > > I studied a bit the testing sites you gave me. I noticed > > > that the download diff link in reviewboard does not work > > > well with rekonq and konqueror (filename info NOT used). If > > > I understood things well, the content-disposition header > > > should be checked for filenames also having the "inline" > > > value. So, something like: > > > if(value.startsWith(QL1S("attachment"),...) || > > > value.startsWith(QL1S("inline")...) > > > > > > I tested on rekonq code and it seems working. > > > > Dawit Alemayehu wrote: > > Nope. kio_http will always ignore the file name parameter if > > content-disposition header contains the "inline" parameter. > > Even if the content sent is not something that user-agent can > > render, the file name should be ignored regardless. For > > example, for the inlwithasciifilename test at > > http://greenbytes.de/tech/tc2231/ you should not see the file > > name if you choose to click "save" when prompted. In fact, the > > correct implementation for inline content would be to display > > it embeded in the application whenever possible, but that is > > not something that can be done generically in kwebpage since > > not all application are KParts based. Note, some browsers > > incorrectly use the "filename" parameter for > > > > BTW, I have now removed the code you quoted above, the one that > > does its own content-disposition parsing in kwebpage. It was a > > left over and unnecessary hack to workaround bugs in the > > kio_http's content-disposition parser. However, it is much > > better to fix the issues at kio_http level than to do this hack > > for sake of consistency in all KDE web rendering modules, not > > just those based on QtWebKit. > > On second thought since khtml seems to also use the filename even for > "inline" content-disposition types, I have fixed the static > extractSuggestedFileName function to return the value of the "filename" > regardless of the content-disposition type.
Which is the better aproach IMHO. This is e.g. useful when you have some sort of web thing where you first view say a PDF inline and then decide to save it. The URL is probably something like /foo/viewAttachment.php which is completely useless for saving. Regarding the disposition-type: everything that is not "inline" should be treated as attachment until other types are defined. Eike
signature.asc
Description: This is a digitally signed message part.
