This should be fixed for the upcoming KDE 4.8.0 release. See
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/0b810d76

This error continues under version 4.8 RC1 (4.7.95).

(In reply to comment #2)
> This error continues under version 4.8 RC1 (4.7.95).

What type of file are you trying to open ? A text file, a PDF ? Can you provide the address to the webdav server where you see this issue ?

The server is webdavs://cjcitycentro.org:2078/ I can try give you access.
I have tried to open a txt file and a tar.gz and neither has worked for me.

(In reply to comment #4)
> The server is webdavs://cjcitycentro.org:2078/ I can try give you access.
> I have tried to open a txt file and a tar.gz and neither has worked for me.

Please send me the access information to the personal email you see in this bug report.

You webdav server, which I assume is apache with mod_dav, returns "httpd/unix-file" as the content type for each file. Hence, this issue. You need to enable the ability for mod_dav to correctly set the content-type for each file type. 

I even tried to workaround this by ignoring the mime-type it sends when it is "httpd/unix-file", but unfortunately that only helps with the proper icon being displayed when it is listed. The minute you attempt to retrieve the file, your sever returns another bogus mime-type "application/download". Hence, this is not something we can workaround. You need to fix your server.

Just a guess... You probably do not have mod_mime[1] enabled in your apache server ?


[1] http://httpd.apache.org/docs/2.2/mod/mod_mime.html

The server is a shared hosting with http://www.redcoruna.com
I will try to contact them to solve it but the same problem can occur with other shared servers.

Will this be a bug of Apache that should send "application/octet-stream" instead of "application/download"?

(In reply to comment #8)
> The server is a shared hosting with http://www.redcoruna.com
> I will try to contact them to solve it but the same problem can occur with
> other shared servers.
> 
> Will this be a bug of Apache that should send "application/octet-stream"
> instead of "application/download"?

Yes, but it does not seem to me to be a bug. It is rather a misconfiguration of Apache. Your apache installation does not seem have "mod_mime" installed. Hence, it is sending whatever default values it has built-in. For web dav that would be "httpd/unix-file" or "httpd/unix-directory" based on what you are doing.

And yes it should at minimum return the default mime-type ("application/octet-stream") instead of a bogus "application/download" mimetype. All of that points to a server misconfiguration...

I has spoken with me hosting and it has said that mod_mime is installed.
Maybe the problem can be CPanel that is the tool used to make the webdav directories.

*** Bug 324153 has been marked as a duplicate of this bug. ***

This bug is still in 4.11.3 using the webdav of 1&1 webdavs://webdav.office.1und1.de
Following comment #7, is there a way I can check for the apache extention from external?

Problem still exists in 4.12.3

I checked this with a different webdavs-server (mediacenter.gmx.net), same behaviour.
mimetypes work for sftp connections.

This bug is IMHO not only important, it is as well getting urgent, as more people are about to work with webdavs / cloud solutions. I'm about to kick out the Windows-PC in a company, but this stops me at the moment...Any chance that we get a solution soon?

(In reply to comment #14)
> I checked this with a different webdavs-server (mediacenter.gmx.net), same
> behaviour.
> mimetypes work for sftp connections.
> 
> This bug is IMHO not only important, it is as well getting urgent, as more
> people are about to work with webdavs / cloud solutions. I'm about to kick
> out the Windows-PC in a company, but this stops me at the moment...Any
> chance that we get a solution soon?

There is nothing we can do about the server sending incorrect content type information. For example, the test webdav servers you find at http://boonfaya.com/sites/webdavapps.com/#targets all return incorrect content type (text/plain) for any content:

io_http(4854)/kio_http_debug HTTPProtocol::readBody: "1978" bytes left.
kio_http(4854)/kio_http_debug HTTPProtocol::readBody: EOD received! Left = "0"
kio_http(4854)/kio_http_debug HTTPProtocol::cacheFileClose:
kio_http(4854)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(4854)/kio_http_debug updateUDSEntryMimeType: item: "." , mimeType: ""
kio_http(4854)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(4854)/kio_http_debug updateUDSEntryMimeType: item: "Demo Image - Northern Lights.jpg" , mimeType: "text/plain"

Notice how it returned text/plain for a JPEG file. On the other hand the owncloud test webdav server at webdav://demo.owncloud.org/remote.php/webdav/ returns the correct content type:

kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo Image - Northern Lights.jpg" , mimeType: "image/jpeg"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo Movie OGG - Big Bug Bunny Trailer.ogg" , mimeType: "audio/ogg"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo MP3 - E.J. - Blick Zurück.mp3" , mimeType: "audio/mpeg"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo PDF - Alice in Wonderland.pdf" , mimeType: "application/pdf"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo Presentation - Bored.impress" , mimeType: "text/impress"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "Demo Textfile - License.txt" , mimeType: "text/plain"
kio_http(5469)/kio_http_debug HTTPProtocol::davParsePropstats: Got status code 404 (this may mean that some properties are unavailable)
kio_http(5469)/kio_http_debug updateUDSEntryMimeType: item: "New Document.odt" , mimeType: "application/vnd.oasis.opendocument.text"

I am almost certain the webdav servers you are testing against return bogus content type information like the first example I provided. I dunno what we can do about that since we always rely on the server to tell us the content type.

(In reply to comment #15)

> I am almost certain the webdav servers you are testing against return bogus
> content type information like the first example I provided. I dunno what we
> can do about that since we always rely on the server to tell us the content
> type.

Thanks for your verbose analysis. To get the large companies to fix their servers will be almost impossible unless you have some media echo around it.
Alternative would be to work around it it and at least look for the file extention to guess the right application.
Anyway, I would like to debug the two servers I work with. I you could provide me some information on how to do that ...I'm more a user than a programmer (at least in the KDE context). 
Thanks in advance!

*** Bug 299914 has been marked as a duplicate of this bug. ***

Definitely there was a problem with webdav configurate using CPanel. You can see more info in https://forums.cpanel.net/threads/case-104037-webdavs-server-webdisk-sending-wrong-mime-type.410812/

I don't know if in recent versions of CPanel the bug was corrected but i think that we can close this bug.

I have seen that some webdav servers seen mimetype 'httpd/unix-file' when they can not obtain the correct mimetype (Example https://rt.cpan.org/Public/Bug/Display.html?id=60883 ) I don't know if in this case a workaround to ignore this default mimetype could be sense.