> On Dec. 1, 2012, 7:07 p.m., Dawit Alemayehu wrote: > > 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. > > Sergey Borovkov wrote: > 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 >
Personally I would not use KIO::mimetype for any protocol unless there is an actual reason, e.g. I am simply listing the contents of a server. Then the chances the contents of any particular resource being are needed is rather small. Otherwise, I would simply use KIO::get and the put ioslave on hold functionality described in its API documentation because at some point right afterwards I will be retreiving the content. As far as the response from the webserver, I personally do not see anything wrong with it. A server is not under any obligation to send the content-type if it actually does not understand the client's request. That seems to be the case here. The server responded with a 415. That means it did not support or understand the request. As such it correctly returned a header that does not include a content type. A client can only reasonably expect to receive a valid mimetype when a server responds with a 2xx status code. The only issue I see is that what you posted above is done the curl. Can you enable the debug areas for kio_http following the instructions outlined at the link below and see what you get with kio_http instead ? The debug areas of interest are 7103 and 7113. You might need to install the debug versions of kdelibs for your distro if you did not compile from source. Otherwise, make sure you compiled in "RelWithDebInfo" or "Debug" cmake modes. [1] http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves#How_to_get_debug_output - Dawit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107518/#review22888 ----------------------------------------------------------- On Nov. 29, 2012, 5:42 p.m., Sergey Borovkov wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107518/ > ----------------------------------------------------------- > > (Updated Nov. 29, 2012, 5:42 p.m.) > > > Review request for kdelibs. > > > Description > ------- > > 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. > > > Diffs > ----- > > kioslave/http/http.h 4d0b029 > kioslave/http/http.cpp b7f8e8d > > Diff: http://git.reviewboard.kde.org/r/107518/diff/ > > > Testing > ------- > > Tested this on two webdav servers (webdavs://webdav.yandex.ru and > webdavs://dav.2safe.com). > > > Thanks, > > Sergey Borovkov > >
