threads / discuss / 55832

why does git-send-email unwrap headers?

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

## tl;dr

3 messages between Jun 2, 2021 and Jun 2, 2021.

replies: 2people: 2as markdown or json

Konstantin Ryabitsev· Jun 2, 2021, 15:34 UTC · lore

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

Taylor Blau· Jun 2, 2021, 16:53 UTC · re: Konstantin Ryabitsev · lore

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

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

Konstantin Ryabitsev· Jun 2, 2021, 18:04 UTC · re: Taylor Blau · lore

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

On Wed, Jun 02, 2021 at 12:53:39PM -0400, Taylor Blau wrote:

Show 9 quoted lines

> 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