Allow override of Content-Type header for web-based calls

[chiefy]

Not sure of the best way to implement this, but currently all web-based requests come back with Content-Type: text/plain which in general is probably ok, but if the command is returning JSON or something, it'd be handy to be able to set the header accordingly.

[progrium]

Heh. So CGI says you can specify headers (namely Content-Type) by outputting them first before a newline and empty line. I'm guess that's how we'd want to do it. Unless we want to also auto-detect JSON output since that's so common.....

[chiefy]

Yeah the only problem is that the response writer automatically injects headers before sending request so it seems like a chicken/egg problem...

< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Connection: keep-alive
< Date: Mon, 12 Jun 2017 17:36:56 GMT
< Content-Length: 88
< Content-Type: text/plain; charset=utf-8
<
Content-Type: application/json

{"text": "Hello, chiefy", "response_type": "in_channel"}

[progrium]

Yeah if it's optional it gets harder to properly determine if it's provided. And my idea of detecting JSON would mean buffering output.

Not ruling anything out yet, but anybody have other ideas?

[progrium]

One idea is to put it in command metadata. I think there is a proposal somewhere about expanding the cmd script format to do something like:

#!cmd alpine bash
#!cmd onbuild: some bash
#!cmd content-type: application/json
#!/bin/bash
...

This would mean this command is always application/json though. But that's a step up from always text/plain for all commands. However, this would depend on the refactoring of our script building system. And formalizing a proposal for this meta-data idea.

[mattatcha]

@progrium were you thinking of just using http.DetectContentType? https://golang.org/pkg/net/http/#DetectContentType

Edit: After looking at the src it looks like json won't be detected

[progrium]

General idea, but yes relevant types.