pgnus 0.25 problem

pgnus 0.25 problem

[Jakub Martyński]

Hi.

I found problem in Pgnus 0.25:

Signaling: (error "Invalid header: text/plain;")
  signal(error ("Invalid header: text/plain;"))
  cerror("Invalid header: %s" "text/plain;")
  apply(cerror ("Invalid header: %s" "text/plain;"))
  error("Invalid header: %s" "text/plain;")
  drums-parse-content-type("text/plain;")
  article-decode-charset()
  run-hooks(article-decode-charset)
  gnus-request-article-this-buffer(15901 "pl.comp.os.linux")
  gnus-article-prepare(15901 nil)
  gnus-summary-display-article(15901 nil)
  gnus-summary-select-article(nil nil pseudo)
  gnus-summary-scroll-up(1)
  call-interactively(gnus-summary-scroll-up)  


Pozdrowienia, 
	 Kuba.
-- 
martinez@sex.info,pl

Re: pgnus 0.25 problem

[Lars Magne Ingebrigtsen]

Jakub.Martynski@spam.is.lame.org (Jakub Martyñski) writes:

> I found problem in Pgnus 0.25:
> 
> Signaling: (error "Invalid header: text/plain;")
>   signal(error ("Invalid header: text/plain;"))

Which brings us to a general question -- what is Gnus supposed to do
with broken headers?  Signalling errors is much too drastic, but
should it just ignore them?  Or try to do something with them?  And if 
so, what?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: pgnus 0.25 problem

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jakub.Martynski@spam.is.lame.org (Jakub Martyński) writes:
> 
> > I found problem in Pgnus 0.25:
> > 
> > Signaling: (error "Invalid header: text/plain;")
> >   signal(error ("Invalid header: text/plain;"))
> 
> Which brings us to a general question -- what is Gnus supposed to do
> with broken headers?  Signalling errors is much too drastic, but
> should it just ignore them?  Or try to do something with them?  And
> if so, what?

"Be conservative in what you send; be liberal with what you receive."

Applied to Gnus, this means that it should try to be as lax as
possible when parsing the headers (in the above case, it should ignore 
the semicolon and perhaps assume the charset is latin1), and ignore
them when they're totally bogus.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Union break!

Re: pgnus 0.25 problem

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > > Signaling: (error "Invalid header: text/plain;")

[...]

> Applied to Gnus, this means that it should try to be as lax as
> possible when parsing the headers (in the above case, it should ignore 
> the semicolon and perhaps assume the charset is latin1), and ignore
> them when they're totally bogus.

Yeah, but (in general) being tolerant is much, much work, because one
has to guess, and guessing is boring.  In this case, just ignoring the 
entire header would leave you with the default (text/plain; us-ascii), 
which is nice.

So I think (since I'm lazy) that Gnus should completely ignore invalid 
headers.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: pgnus 0.25 problem

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> So I think (since I'm lazy) that Gnus should completely ignore invalid 
> headers.

I quite agree.  Also, there is a problem I observed a few times as false
matches, that is, headers which are not headers.  If you increase Gnus
lenience to errors, you also increase the probability of false matches.

Best would be to ignore invalid headers in general, and wait many months
for collecting experience about them.  If some wrong situation reveals to be
frequent and important, maybe Gnus should *then* give in this special case.
Such an attitude might add a bit of an incentive for people to fix their
mailers.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: pgnus 0.25 problem

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > > Signaling: (error "Invalid header: text/plain;")
> 
> [...]
> 
> > Applied to Gnus, this means that it should try to be as lax as
> > possible when parsing the headers (in the above case, it should ignore 
> > the semicolon and perhaps assume the charset is latin1), and ignore
> > them when they're totally bogus.
> 
> Yeah, but (in general) being tolerant is much, much work, because one
> has to guess, and guessing is boring.

Well, I'm not saying you should go out of your ways to interpret what
various moronic mailers *meant* to put in their headers; I'm saying
that it would be nice to handle some more, uh, wide-spread cases of
abuse.  The VM variables I posted contained several such examples.

> In this case, just ignoring the entire header would leave you with
> the default (text/plain; us-ascii), which is nice.

Yup.

> So I think (since I'm lazy) that Gnus should completely ignore
> invalid headers.

I agree, but I do argue for a laxer definition of invalid.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
What is mind?  No matter.
What is matter?  Never mind.

Re: pgnus 0.25 problem

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Hrvoje Niksic said:

  Hrvoje> Applied to Gnus, this means that it should try to be as lax
  Hrvoje> as possible when parsing the headers (in the above case, it
  Hrvoje> should ignore the semicolon and perhaps assume the charset
  Hrvoje> is latin1), and ignore them when they're totally bogus.

I think completely ignoring them is not the right thing.  Suppose I
get a message which looks bogus when shown by Gnus.  I might then
assume that it really *is* bogus.  But maybe just the headers are
bogus, and with some manual effort, the message itself can be
salvaged.  Therefore I propose that at least a message be output
telling the user that Gnus is (otherwise) ignoring the bogus Frumple
header.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: pgnus 0.25 problem

[Hrvoje Niksic]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> >>>>> On 11 Sep 1998, Hrvoje Niksic said:
> 
>   Hrvoje> Applied to Gnus, this means that it should try to be as lax
>   Hrvoje> as possible when parsing the headers (in the above case, it
>   Hrvoje> should ignore the semicolon and perhaps assume the charset
>   Hrvoje> is latin1), and ignore them when they're totally bogus.
> 
> I think completely ignoring them is not the right thing.  Suppose I
> get a message which looks bogus when shown by Gnus.  I might then
> assume that it really *is* bogus.  But maybe just the headers are
> bogus, and with some manual effort, the message itself can be
> salvaged.

Well, then ignoring the headers is exactly the right thing.  If/when
you fix the header, Gnus will no longer ignore it.

Printing a warning that a header is bogus still counts as ignoring it, 
as far as message rendering is concerned.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: pgnus 0.25 problem

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Hrvoje Niksic said:

  Hrvoje> Printing a warning that a header is bogus still counts as
  Hrvoje> ignoring it, as far as message rendering is concerned.

Yeah, I just didn't know that was the definition of ignore we were
talking about :-)

Gnus-warning: This message has bogus MIME (I think) headers!

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: pgnus 0.25 problem

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

>   Hrvoje> Printing a warning that a header is bogus still counts as
>   Hrvoje> ignoring it, as far as message rendering is concerned.
> 
> Yeah, I just didn't know that was the definition of ignore we were
> talking about :-)
> 
> Gnus-warning: This message has bogus MIME (I think) headers!

There are many headers in an RFC1036 message, and they may all be
mangled.  Gnus ignores the ones that are heavily mangled, while trying 
to make do with headers that are important and commonly mangled in
common ways.  (Like, for instance, References headers with broken
Message-IDs).  But the default action Gnus takes when it doesn't
understand what it's fed it to ignore the header and do something
default instead.

I don't think adding headers like this is the way to tell the user
what has been done.  A message may be, though.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen