Bug 22838 - Warning from runreport.pl 'Explicitly setting a MIME header field (content-type) is dangerous'
Summary: Warning from runreport.pl 'Explicitly setting a MIME header field (content-t...
Status: RESOLVED DUPLICATE of bug 22343
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Arthur Suzuki
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-03 14:26 UTC by Nick Clemens
Modified: 2021-02-16 13:48 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 22838: Remove MIME header warnings from runreports.pl (1.79 KB, patch)
2019-12-17 15:14 UTC, Arthur Suzuki
Details | Diff | Splinter Review
Bug 22838: Remove MIME header warnings from runreports.pl (1.85 KB, patch)
2019-12-20 11:40 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 22838: Specify a content-type for other formats (1.05 KB, patch)
2019-12-26 12:31 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2019-05-03 14:26:13 UTC
Explicitly setting a MIME header field (content-type) is dangerous:
use the attr() method instead.
 at misc/cronjobs/runreport.pl line 312.


It seems the error comes from Koha/Email.pm:
 72     $mail{'Content-Type'} = $params->{contenttype} if $params->{contenttype};
Comment 1 Arthur Suzuki 2019-12-17 15:14:48 UTC
Created attachment 96383 [details] [review]
Bug 22838: Remove MIME header warnings from runreports.pl

Test plan:
 - create a savedsql report
 - run misc/cronjob/runreport.pl with options --format set to html and --to any email
 - check plack errors log, you should get a warning
 - apply patch
 - repeat runreport.pl step
 - check plack errors log, no additional warning there should be
Comment 2 Nick Clemens 2019-12-20 11:40:31 UTC
Created attachment 96515 [details] [review]
Bug 22838: Remove MIME header warnings from runreports.pl

Test plan:
 - create a savedsql report
 - run misc/cronjob/runreport.pl with options --format set to html and --to any email
 - check plack errors log, you should get a warning
 - apply patch
 - repeat runreport.pl step
 - check plack errors log, no additional warning there should be

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 3 Jonathan Druart 2019-12-26 12:31:29 UTC
Created attachment 96641 [details] [review]
Bug 22838: Specify a content-type for other formats
Comment 4 Jonathan Druart 2019-12-26 12:31:55 UTC
(In reply to Jonathan Druart from comment #3)
> Created attachment 96641 [details] [review] [review]
> Bug 22838: Specify a content-type for other formats

What about this patch? Should not we set content-type for other formats as well?
Comment 5 Marcel de Rooy 2020-01-10 09:32:07 UTC
Looking here
Comment 6 Marcel de Rooy 2020-01-10 09:51:32 UTC
$msg->attr("content-type" => $contenttype);
See first comment. This is not recommended. Normally you use Type in MIME::Lite.

Furthermore it seems that the same content-type now is applied to both message and attachment. Obviously, they could be different and should be handled individually.

This needs some more attention.
Comment 7 Koha Team University Lyon 3 2020-10-22 12:37:05 UTC
When we run runreport.pl with format option as html (koha version 19.11), we still obtain this warning :
"Explicitly setting a MIME header field (content-type) is dangerous:
use the attr() method instead.
 at runreport.pl line 326"

We don't get it with format=csv.

Olivier Crouzet
Comment 8 Koha Team University Lyon 3 2021-02-16 10:02:35 UTC
Hello,
could someone have a look at this one?
Thanks,

Sonia
Comment 9 Jonathan Druart 2021-02-16 13:48:42 UTC
On master:
kohadev-koha@kohadevbox:/kohadevbox/koha$ perl misc/cronjobs/runreport.pl 2 --format html --to foo@example.org

It does not return any warnings.

Certainly fixed by bug 22343.

*** This bug has been marked as a duplicate of bug 22343 ***