On Sun, Oct 19, 2008 at 01:08:36AM +0000, corvid wrote:
Tomas wrote:
My mistake - Content-type was indicated incorrectly though dillo is the first browser not to render it.
I think the idea is that we don't want to render application/xhtml+xml when we wouldn't be guaranteeing that it's valid.
Yes. The standard requires a validating browser. BTW, dillo CAN render the page without problems, it's disabled because of the standard.
The difference is that in the polarhome case it pops up a "save as" window & in this one it doesn't (even it should). The web page I used here is http://tkhtml.tcl.tk/hv3.html (try to click on any file which should be downloaded).
Oh, I see now. I'll patch that if nobody comes up with a reason why I shouldn't. (It's the only AbortEntry case where OfferDownload isn't set, so it might be deliberate.)
A type mismatch between what the server says it is sending and the actual data, is taken with suspicion by dillo. Unfortunately some servers send downloadable files as text/plain, relying on the data guessing made by the browser (last option as from the SPECs). This is the case. Now, considering that when the server doesn't send Content-Type there's no mismatch, I think it's safe to offer a download. It be good to get a message with the mismatched types on the console too. -- Cheers Jorge.-