| Message ID | 87d0y7e9vg.fsf@linkitivity.dja.id.au |
|---|---|
| State | Accepted |
| Headers | show |
| Series | skip original Content-Transfer-Encoding for mbox | expand |
----- Original Message ----- > From: "Daniel Axtens" <dja@axtens.net> > To: patchwork@lists.ozlabs.org, vkabatov@redhat.com, "yuri volchkov" <yuri.volchkov@gmail.com> > Sent: Monday, May 7, 2018 5:57:55 PM > Subject: [PATCH] skip original Content-Transfer-Encoding for mbox > > In the commit 01b9cbb9 all original mail headers are copied into the > resulted mbox file. This means that some headers are going to be > present twice in the generated mbox. That is fine unless the original > email arrived in base64 encoding. > > Apparently git relies on the latest Content-Transfer-Encoding key. And > since downloaded patch's actual encoding is '7bit', git fails to apply > it with the message 'Patch is empty'. > > Since patchwork adds a proper 'Content-Transfer-Encoding' anyways, > let's skip this field while copying headers from the original mail > > Signed-off-by: Yuri Volchkov <yuri.volchkov@gmail.com> > --- > > Daniel Axtens writes: Yuri sent me an email saying his message didn't > reach the list, so I'm forwarding this on his behalf. Veronika: you > authored 01b9cbb9 so perhaps you could take a look to see if this is the > best way. My guess is that this is probably right but you might have > other thoughts. > Hm, I didn't meet with any base64-encoded emails that weren't autoconverted on their way so I didn't run into this issue. I agree that since the Content-Transfer-Encoding header is added based on the charset (which we pass on message creation), skipping the original header is both the easiest and correct way to solve this problem. Acked-by: Veronika Kabatova <vkabatov@redhat.com> > --- > patchwork/views/utils.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/patchwork/views/utils.py b/patchwork/views/utils.py > index f5ff43c..2357ab8 100644 > --- a/patchwork/views/utils.py > +++ b/patchwork/views/utils.py > @@ -99,6 +99,8 @@ def _submission_to_mbox(submission): > > orig_headers = HeaderParser().parsestr(str(submission.headers)) > for key, val in orig_headers.items(): > + if key == 'Content-Transfer-Encoding': > + continue > mail[key] = val > > if 'Date' not in mail: > -- > 2.17.0 >
Stephen has kindly applied this. Veronika Kabatova <vkabatov@redhat.com> writes: > ----- Original Message ----- >> From: "Daniel Axtens" <dja@axtens.net> >> To: patchwork@lists.ozlabs.org, vkabatov@redhat.com, "yuri volchkov" <yuri.volchkov@gmail.com> >> Sent: Monday, May 7, 2018 5:57:55 PM >> Subject: [PATCH] skip original Content-Transfer-Encoding for mbox >> >> In the commit 01b9cbb9 all original mail headers are copied into the >> resulted mbox file. This means that some headers are going to be >> present twice in the generated mbox. That is fine unless the original >> email arrived in base64 encoding. >> >> Apparently git relies on the latest Content-Transfer-Encoding key. And >> since downloaded patch's actual encoding is '7bit', git fails to apply >> it with the message 'Patch is empty'. >> >> Since patchwork adds a proper 'Content-Transfer-Encoding' anyways, >> let's skip this field while copying headers from the original mail >> >> Signed-off-by: Yuri Volchkov <yuri.volchkov@gmail.com> >> --- >> >> Daniel Axtens writes: Yuri sent me an email saying his message didn't >> reach the list, so I'm forwarding this on his behalf. Veronika: you >> authored 01b9cbb9 so perhaps you could take a look to see if this is the >> best way. My guess is that this is probably right but you might have >> other thoughts. >> > > Hm, I didn't meet with any base64-encoded emails that weren't autoconverted > on their way so I didn't run into this issue. I agree that since the > Content-Transfer-Encoding header is added based on the charset (which we > pass on message creation), skipping the original header is both the easiest > and correct way to solve this problem. > > Acked-by: Veronika Kabatova <vkabatov@redhat.com> > > >> --- >> patchwork/views/utils.py | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/patchwork/views/utils.py b/patchwork/views/utils.py >> index f5ff43c..2357ab8 100644 >> --- a/patchwork/views/utils.py >> +++ b/patchwork/views/utils.py >> @@ -99,6 +99,8 @@ def _submission_to_mbox(submission): >> >> orig_headers = HeaderParser().parsestr(str(submission.headers)) >> for key, val in orig_headers.items(): >> + if key == 'Content-Transfer-Encoding': >> + continue >> mail[key] = val >> >> if 'Date' not in mail: >> -- >> 2.17.0 >>
diff --git a/patchwork/views/utils.py b/patchwork/views/utils.py index f5ff43c..2357ab8 100644 --- a/patchwork/views/utils.py +++ b/patchwork/views/utils.py @@ -99,6 +99,8 @@ def _submission_to_mbox(submission): orig_headers = HeaderParser().parsestr(str(submission.headers)) for key, val in orig_headers.items(): + if key == 'Content-Transfer-Encoding': + continue mail[key] = val if 'Date' not in mail:
In the commit 01b9cbb9 all original mail headers are copied into the resulted mbox file. This means that some headers are going to be present twice in the generated mbox. That is fine unless the original email arrived in base64 encoding. Apparently git relies on the latest Content-Transfer-Encoding key. And since downloaded patch's actual encoding is '7bit', git fails to apply it with the message 'Patch is empty'. Since patchwork adds a proper 'Content-Transfer-Encoding' anyways, let's skip this field while copying headers from the original mail Signed-off-by: Yuri Volchkov <yuri.volchkov@gmail.com> --- Daniel Axtens writes: Yuri sent me an email saying his message didn't reach the list, so I'm forwarding this on his behalf. Veronika: you authored 01b9cbb9 so perhaps you could take a look to see if this is the best way. My guess is that this is probably right but you might have other thoughts. --- patchwork/views/utils.py | 2 ++ 1 file changed, 2 insertions(+)