Re: Header folding

Mark Overmeer <[email protected]> Thu, 19 Aug 2004 10:33:54 +0200
Newsgroups gmane.comp.lang.perl.modules.mail-box
Organization MARKOV Solutions
Message-ID <[email protected]>
* David A Golden ([email protected]) [040818 23:48]:
> I looked a little further at this issue.  It appears to be a result of
> parsed fields not getting folded.  Also, the parser tries to make sure
> that every header field body ends in "\n", whereas  setWrapLength assumes
> that a field is already folded if called with no argument and if the body
> ends in "\n".  So just calling setWrapLength on parsed headers doesn't help
> as any parsed line is assumed to be folded.  

Mail::Message::Field::setWrapLength() reads:

  sub setWrapLength(;$)
  {   my $self = shift;
                                                                                
      $self->[1] = $self->fold($self->[0],$self->unfoldedBody, @_)
          if @_ || $self->[1] !~ m/\n$/;
                                                                                
      $self;
  }

In human translation, this says: fold the unfolded version of the body
when either a wrap-length is provided (in @_) or the line is not folded
yet (isn't terminated by a \n).

Where I try to be strict on, is that there are two different ways you
can have the body (the contents) of a field in:
  1) unfolded form: no new-lines at all
  2) folded form: newline after each line.

For instance:

 X-Postal: The White House
  1600 Pennsylvania Avenue NW
  Washington, DC 20500

The unfolded version will be:
  "The White House 1600 Pennsylvania Avenue NW Washington, DC 20500"

The folder version will be equivalent to
    " The White House\n"
  . " 1600 Pennsylvania Avenue NW\n"
  . " Washington, DC 20500\n"

No intermediate versions of the field content should exist.

One big issue with your proposed solution (removing the last \n
everywhere) is that a line me be ending on \r\n  :-(  and that
should be honoured.

So... I do not see a bug (be that can be my limited view on the world)
and therefore no reason to fix things.  Tell me if I'm wrong.
-- 
               MarkOv

------------------------------------------------------------------------
drs Mark A.C.J. Overmeer                                MARKOV Solutions
       [email protected]                          [email protected]
http://Mark.Overmeer.net                   http://solutions.overmeer.net