<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://git.reviewboard.kde.org/r/107518/">http://git.reviewboard.kde.org/r/107518/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On December 1st, 2012, 7:07 p.m., <b>Dawit Alemayehu</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Why not simply use KIO::get instead of KIO::mimetype ? For the record, one should never use KIO::mimetype for HTTP based protocols since it results in a HEAD request. It is a well known issue that sending a HEAD request to webservers, which for the most part generate content dynamically, is a useless proposition because the mime type they return on such request will be wrong most of the time (HEAD will not result in the generation of the content and hence the default type will probably be returned). Hence, the rule about not using KIO::mimetype for HTTP or any of its extensions like webdav. Instead you should simply do a KIO::get request by following the instructions on how to put a request on hold if all you want to do is determine the real mimetype of the content. This has even the side benefit of being able to use the same connection if you then decide to pull down the content afterwards. 

Havig said that, I am unable to test your patch because I do not have access. The links you provided are protected by HTTP authorization.</pre>
 </blockquote>







</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, those links need authorization (unfortunately I don't know any webdav:// links that do not require it). About using KIO::get - thanks for useful infrmation, I did not know about this rule about not using KIO::mimetype for HTTP (did not see it anywhere), still it's really inconvenient to create additional code path for some protocols. Anyway bug when KIO::mimetype() returns just empty string is really annoying :( From what I understand it should never do that.

Btw, just a sample ouptput from webdav.yandex.ru when doing HEAD request ( user and password omitted:) ):
curl -I https://webdav.yandex.ru
HTTP/1.1 415 Unsupported Media Type
Yandex-Uid: 161224872
Server: MochiWeb/1.0
Keep-Alive: timeout=300
Date: Sat, 01 Dec 2012 19:48:57 GMT
Content-Length: 0
</pre>
<br />








<p>- Sergey</p>


<br />
<p>On November 29th, 2012, 5:42 p.m., Sergey Borovkov wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/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.</div>
<div>By Sergey Borovkov.</div>


<p style="color: grey;"><i>Updated Nov. 29, 2012, 5:42 p.m.</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;">KIO::mimetype() when used on webdav:// url returned empty string on some servers, empty string on others. After some investigating I found out that mime-type is determined like for usual http:// links - i.e. making HEAD requests.
But this is problematic - some servers do not return content type for webdav links (for example this behavior occurred on webdavs://webdav.yandex.ru). Even if server returns content-type it can be wrong - for directories HEAD request return text/xml (that happens because webdav directories are simply xml listings).
I tried to fix this by essentially calling stat on webdav url and emitting mimetype when it's found.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </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;">Tested this on two webdav servers (webdavs://webdav.yandex.ru and webdavs://dav.2safe.com).</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>kioslave/http/http.h <span style="color: grey">(4d0b029)</span></li>

 <li>kioslave/http/http.cpp <span style="color: grey">(b7f8e8d)</span></li>

</ul>

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




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








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