aggregate web trigger sends response as text/plain

With IkiWiki 3.20200202.3, aggregate's web trigger sends it's response as HTTP 200, Content-Type: text/plain, followed by a payload that seems to include a Content-type in the body accidentally, and a bunch of HTML:

qusp▶ GET -e "https://$redacted/ikiwiki?do=aggregate_webtrigger"
Enter username for Git Access at REDACTED:443: admin
Password: 
200 OK
Connection: close
Date: Mon, 20 Apr 2020 08:27:39 GMT
Server: nginx/1.14.2
Content-Length: 2467
Content-Type: text/plain
Client-Date: Mon, 20 Apr 2020 08:27:39 GMT
Client-Peer: 31.51.75.214:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client-SSL-Cert-Subject: /CN=REDACTED
Client-SSL-Cipher: ECDHE-RSA-CHACHA20-POLY1305
Client-SSL-Socket-Class: IO::Socket::SSL

Aggregation triggered via web.

Content-type: text/html

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
…

Looking at the source it's fairly clear why: http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Plugin/aggregate.pm;hb=HEAD#l76

I guess it was never intended for a human to see this output. I've found it useful to add a link button to some private pages to manually trigger the web hook, something like

<a class=feedbutton href=https://REDACTED/ikiwiki?do=aggregate_webtrigger>webtrigger</a>

So it would be nice if the payload was sent with a HTML content-type (which wouldn't hurt cron jobs or clients that ignore the body anyway)

— Jon, 2020-04-20

Oh, haha, the issue here is that the aggregation is failing. In the failure case, the above happens (there's an error wrapped up in HTML and delivered as text/plain). In the success case, the output to browser is just plain text. — Jon, 2020-04-20