Removing ignore-errors in mm-dissect-buffer

Removing ignore-errors in mm-dissect-buffer

[Reiner Steib]

Hi,

Gnus errors out with "forward-sexp: Scan error: "Unbalanced
parentheses", 21, 32" when displaying the following spam article:

,----[ http://theotp1.physik.uni-ulm.de/~ste/tmp/gmane.emacs.diffs.46183 ]
| Newsgroups: gmane.emacs.diffs
| Subject: Core@mindyfunk.com
| Date: Sun, 12 Feb 2006 22:41:42 -0500 (EST)
| Message-ID: <20060213034142.06497AA36A4@max.barkingdogstudios.com>
| Mime-Version: 1.0
| Content-Type: multipart/mixed; boundary=fc55ff24ae7d5dde3b9cddf90cbc0f08
`----

The culprit is the string «charset=\"us-ascii\"» in the first MIME
part which might be invalid:

,----
| --fc55ff24ae7d5dde3b9cddf90cbc0f08
| Content-Type: text/html; charset=\"us-ascii\"
| MIME-Version: 1.0
| Content-Transfer-Encoding: quoted-printable
`----

But Gnus should render the article despite of the broken charset
declaration, I think.

To reproduce (even from «emacs -Q»), eval the following code:

--8<---------------cut here---------------start------------->8---
(require 'mail-parse)
(with-temp-buffer
  (insert "Content-Type: text/html; charset=\\\"us-ascii\\\"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable")
  (setq ct (mail-fetch-field "content-type")
	ctl (and ct (mail-header-parse-content-type ct))))
--8<---------------cut here---------------end--------------->8---

Reverting mm-decode.el to revision 7.37 fixed the problem:

--8<---------------cut here---------------start------------->8---
--- mm-decode.el	15 Feb 2006 17:33:53 +0100	7.37
+++ mm-decode.el	15 Feb 2006 17:33:26 +0100	7.38
@@ -534,13 +534,13 @@
 		  loose-mime
 		  (mail-fetch-field "mime-version"))
 	  (setq ct (mail-fetch-field "content-type")
-		ctl (ignore-errors (mail-header-parse-content-type ct))
+		ctl (and ct (mail-header-parse-content-type ct))
 		cte (mail-fetch-field "content-transfer-encoding")
 		cd (mail-fetch-field "content-disposition")
 		description (mail-fetch-field "content-description")
 		id (mail-fetch-field "content-id"))
 	  (unless from
-		(setq from (mail-fetch-field "from")))
+	    (setq from (mail-fetch-field "from")))
 	  ;; FIXME: In some circumstances, this code is running within
 	  ;; an unibyte macro.  mail-extract-address-components
 	  ;; creates unibyte buffers. This `if', though not a perfect

[...]
--8<---------------cut here---------------end--------------->8---

If reverting the following changes is not the right thing, could you
suggest a better approach, Katsumi?

,----
| 2006-02-07  Katsumi Yamaoka  <yamaoka@jpl.org>
| 
| 	* gnus-art.el (article-decode-charset): Don't use ignore-errors
| 	when calling mail-header-parse-content-type.
| 	(article-de-quoted-unreadable): Ditto.
| 	(article-de-base64-unreadable): Ditto.
| 	(article-wash-html): Ditto.
| 
| 	* mm-decode.el (mm-dissect-buffer): Don't use ignore-errors when
| 	calling mail-header-parse-content-type and
| 	mail-header-parse-content-disposition.
| 	(mm-find-raw-part-by-type): Don't use ignore-errors when calling
| 	mail-header-parse-content-type.
| [...]
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Removing ignore-errors in mm-dissect-buffer

[Katsumi Yamaoka]

>>>>> In <v9wtfwo8zf.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> Gnus errors out with "forward-sexp: Scan error: "Unbalanced
> parentheses", 21, 32" when displaying the following spam article:

I see.  Though the article seems to have been cancelled.

[...]

> The culprit is the string «charset=\"us-ascii\"» in the first MIME
> part which might be invalid:

> ,----
>| --fc55ff24ae7d5dde3b9cddf90cbc0f08
>| Content-Type: text/html; charset=\"us-ascii\"
>| MIME-Version: 1.0
>| Content-Transfer-Encoding: quoted-printable
> `----

> But Gnus should render the article despite of the broken charset
> declaration, I think.

Yes, I think so.  The change I made aimed to cope with
Thunderbird 1.5 which generates wrong name and filename
parameters for an attachment of a long non-ASCII file name[1].
In such a case, now at least type/subtype will be extracted.

> To reproduce (even from «emacs -Q»), eval the following code:

> (require 'mail-parse)
> (with-temp-buffer
>   (insert "Content-Type: text/html; charset=\\\"us-ascii\\\"
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable")
>   (setq ct (mail-fetch-field "content-type")
> 	ctl (and ct (mail-header-parse-content-type ct))))

> Reverting mm-decode.el to revision 7.37 fixed the problem:

[...]

> If reverting the following changes is not the right thing, could you
> suggest a better approach, Katsumi?

I think mail-header-parse-content-type should never cause erros
and it should extract at least type/subtype if it is possible.
I will make an effort so that it might do so.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=323318

Re: Removing ignore-errors in mm-dissect-buffer

[Katsumi Yamaoka]

>>>>> In <b4mwtfwnqf6.fsf@jpl.org> Katsumi Yamaoka wrote:

> I think mail-header-parse-content-type should never cause erros
> and it should extract at least type/subtype if it is possible.
> I will make an effort so that it might do so.

Done.  Now `rfc2231-parse-string' attempts to parse even
parameter values which are surrounded with \"...\" but will
never cause a Lisp error.