> The reason for all the weird behavior is simply that MoinMoin > is trying to do some portion of the work (e.g. mime-typing) > that the web server and/or browser normally do, and messing > it up. A case in point is that when I try to do "save-as" > by right clicking from my browser, my browser uses the page > name, instead of the name of the attached file (because that's > buried in the params in the URL, instead of in the path where > most browsers expect the downloaded file name to be).
Yes, that's a problem that exists since the AttachFile hack was done in some ancient moin version (and it will be fixed when AttachFile is killed, attachments are items, because then their name will be just in the path). Also, that will fix the encoding problems with non-ascii attachment names in the only way that is understood by all current browsers. BUT, it is not as easy: A browser that is using the filename to determine the mimetype of a file it accesses by http is doing it very wrong, because it rather should use the mimetype given in the http headers. Using the extension of the file is OK if you don't have any doable better way, but if a http header tells the browser that "this is text/x-graphviz-dot" (I am making this up), then it should not throw that away and look at its .dot file extension and decide "oh, that is application/msword!". So, if you see such behaviour, file a bug against the browser. :) Moin currently has no way to store additional metadata for attachments (this will change in the future), so what moin currently does IS to look at the filename extension and send that mimetype (this is basically the same what apache does with its mimetype mappings). We have extended the extension -> mimetype mapping table for some cases that were missing, so it behaves better than when just using python stdlib. In future, items will just have mimetype stored as metadata and we will just send that (when accessing the raw item data). > is annoying as all get-out. Instead of trying to manage > the mime-typing, MoinMoin could just use standard URLs, > and let the server and browser "do their thing". If files are handled by moin, the server is not involved at all, moin emits the complete http response. See below for the other case. > IMHO, it would be nice if non-page items (e.g. files) were > accessible from the the web server via direct links > (NOT via the MoinMoin CGI script). That was removed quite a while ago (with good reasons I won't repeat here) after being deprecated for years. It sucked and it won't come back. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Moin-user mailing list Moin-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/moin-user
