[Moin-user] Changing default behavior on downloads.

[Thomas Waldmann]

> 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.