<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://svn.reviewboard.kde.org/r/6183/">http://svn.reviewboard.kde.org/r/6183/</a>
     </td>
    </tr>
   </table>
   <br />








<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On January 5th, 2011, 11:11 a.m., <b>Andrea Diamantini</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
 <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
    <a href="http://svn.reviewboard.kde.org/r/6183/diff/4/?file=43503#file43503line98" style="color: black; font-weight: bold; text-decoration: underline;">trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp</a>
    <span style="font-weight: normal;">

     (Diff revision 4)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
   <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static void extractSuggestedFileName(const QNetworkReply* reply, QString& fileName)</pre></td>

  </tr>
 </tbody>




 
 



 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
    <th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">98</font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">    <span class="k">if</span> <span class="p">(</span><span class="n">value</span><span class="p">.</span><span class="n">startsWith</span><span class="p">(</span><span class="n">QL1S</span><span class="p">(</span><span class="s">"attachment"</span><span class="p">),</span> <span class="n">Qt</span><span class="o">::</span><span class="n">CaseInsensitive</span><span class="p">))</span> <span class="p">{</span></pre></td>
  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
 </blockquote>





</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
<br />




<p>- Dawit</p>


<br />
<p>On January 5th, 2011, 6:21 a.m., Dawit Alemayehu wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://svn.reviewboard.kde.orgrb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for kdelibs and Andrea Diamantini.</div>
<div>By Dawit Alemayehu.</div>


<p style="color: grey;"><i>Updated 2011-01-05 06:21:31</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The attached patch fixes a long standing issue in the KIO-QNAM class where actions that require putting an ioslave on hold currently do not work. In kdewebkit, which uses this integration class, such actions always occur when you click on a link that cannot be directly handled by the browsing engine. For example, clicking on a link that points to a PDF link. Even worse is when the link you click on results in an http POST which returns content. In such cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge class have no way of putting an ioslave on hold as stated in KIO::get's documentation in order to properly deal with content types they do not support.

The attached patch along with another pending against kio_http, http://reviewboard.kde.org/r/6182/ , remedies this issue by adding a means to put replies on hold and fixing the downloadResponse slot in KWebPage to do the right thing.</pre>
  </td>
 </tr>
</table>





<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>trunk/KDE/kdelibs/kdewebkit/ISSUES <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kdewebkit/ISSUES <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kdewebkit/kwebpage.h <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kio/kio/accessmanager.h <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kio/kio/accessmanager.cpp <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h <span style="color: grey">(1211858)</span></li>

 <li>trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp <span style="color: grey">(1211858)</span></li>

</ul>

<p><a href="http://svn.reviewboard.kde.org/r/6183/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>