Review Request: Fix the inability to put an ioslave on hold when using the KIO-QNAM integration class...

[Rolf Eike Beer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110111/8d9545f1/attachment.sig>