Re: url issues

[Dave Love]

Stefan <address@hidden> writes:

> Maybe using mm-insert-part would be preferable, but at least I think my
> change is correct in the sense that it gets the behavior closer to
> the ideal.

The ideal is to DTRT according to the MIME rules (modulo that HTTP
headers aren't actually MIME).  For instance if the transfer encoding
is specified, the data should be decoded.  The idea was always to use
Gnus MIME functions and fix them if necessary, which I did a bit.  One
problem is that it isn't clean of dependencies on the rest of Gnus as
I've often whinged.

> Does mm-insert-part pay attention to -*- coding: foo -*- and to file
> name extension?  These were the motivating reason for my change.

I think it shouldn't, necessarily.  For instance, if the data are of
type `application/octet-stream', they shouldn't be decoded -- in fact,
probably not unless they're `text/...'.  (Probably there should be a
specification of which `application/...' types should count as text.)
The URL's extension should go via `mailcap-mime-extensions'.

I realize that it's not entirely clear what should be done with the
actual data in general.  For instance, W3 makes some effort to extract
a charset from an http-equiv element (which requires an HTML parse).
Other details probably aren't clear-cut, especially in the absence of
useful MIME info, but I never looked at this closely, I'm afraid.

> Of course.  I meant that the charset specified could be used but shouldn't
> be trusted since in practice it's much too often just "the default charset
> implied by the locale under which the http server is running" without paying
> much attention to the file itself.

I think if the charset is specified, it should be obeyed like
`coding-system-for-read'.  Emacs shouldn't be incorrect because some
web servers don't DTRT and penalize systems that do.

> PS: Haven't had time to look at the rest of your points.  If you
> could do those changes yourself, it would be great.

Sorry, I can't.