why does git-send-email unwrap headers?

why does git-send-email unwrap headers?

[Konstantin Ryabitsev]

Hello:

I've noticed that when a message is sent with git-send-email, it will unwrap
all existing headers into a single line, such that:

    Some-header: This is a long header that happens to be longer than 78
     characters and is therefore wrapped at whitespace chars to properly span
     across multiple lines

becomes:

    Some-header: This is a long header that happens to be longer than 78 characters and is therefore wrapped at whitespace chars to properly span across multiple lines

While it's not *wrong* (the 78-character limit is from a very old RFC), I'm
curious if this is intentional or just an oversight.

-K

Re: why does git-send-email unwrap headers?

[Taylor Blau]

On Wed, Jun 02, 2021 at 11:34:41AM -0400, Konstantin Ryabitsev wrote:
> While it's not *wrong* (the 78-character limit is from a very old RFC), I'm
> curious if this is intentional or just an oversight.

My guess is that this dates back to 5012699d98 (send-email: handle
multiple Cc addresses when reading mbox message, 2009-02-14), which
unfolds all multi-line headers, probably so that parsing the header can
be done line-wise without having to keep track of whether you are
parsing a continuation line or not.

Perl's Mail::Header [1] looks to have support for folding a header
across multiple lines, but I'd just as soon defer to the Perl experts
around here for help using it :).

Thanks,
Taylor

[1]: https://metacpan.org/pod/Mail::Header

Re: why does git-send-email unwrap headers?

[Konstantin Ryabitsev]

On Wed, Jun 02, 2021 at 12:53:39PM -0400, Taylor Blau wrote:
> On Wed, Jun 02, 2021 at 11:34:41AM -0400, Konstantin Ryabitsev wrote:
> > While it's not *wrong* (the 78-character limit is from a very old RFC), I'm
> > curious if this is intentional or just an oversight.
> 
> My guess is that this dates back to 5012699d98 (send-email: handle
> multiple Cc addresses when reading mbox message, 2009-02-14), which
> unfolds all multi-line headers, probably so that parsing the header can
> be done line-wise without having to keep track of whether you are
> parsing a continuation line or not.

I think you're right, but I believe simply removing the two lines that do the
actual unwrapping will fix this without causing any side-effects.

I.e. when parsing headers, don't "unwrap" them but merely concatenate all
header lines to the proper header. Address parsing routines should still
properly handle this situation, though it's less clear to me if something else
may be affected by this change.

CC'ing Ævar Arnfjörð Bjarmason, who I think is the person most poking at
git-send-email lately.

-- >8 --

diff --git a/git-send-email.perl b/git-send-email.perl
index 25be2ebd2a..4c79122f78 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1654,8 +1654,6 @@ sub process_file {
        while(<$fh>) {
                last if /^\s*$/;
                if (/^\s+\S/ and @header) {
-                   chomp($header[$#header]);
-                   s/^\s+/ /;
                        $header[$#header] .= $_;
            } else {
                        push(@header, $_);

-- >8 --

-K