Error when testing on Chrome/Firefox: text/html requested but a single column was not selected

[steve-chavez]

PostgREST version: v6.0.0

Problem

Some users might use regular browsers(chrome, firefox, etc) to explore and make quick tests of the API, but since the addition of #1330 this is no longer possible:

GET /projects

{"message":"text/html requested but a single column was not selected"}

This would also have happened for chrome if #1077 was implemented, since this is the Accept header that it sends by default:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3

(See the image/webp and image/apng in there)

Having pgrst behave like this by default is bad for UX. So we shouldn't have image/* or text/html as alias for binary output by default. Though I think text/plain is probably safe.

Allowing Content-Type overriding isn't a solution since that doesn't make pgrst do raw output.

Proposal

My proposal for now would be to add a new config option that lets the user specify the media types for which it would like the raw output and not have text/html by default. Something like:

raw-output-media-types = [ "image/png", "image/jpeg", "text/html" ]

This would solve this issue and #1077.

[dan-amoroso]

I'd like to try to implement this. As a clarification, is the intended - current - use to accept text/html and select one and only one column?

[steve-chavez]

@Dansvidania Actually the use case for text/html was just for pg functions that returned text. It was a mistake on my part to enable it by default for all kind of binary outputs. Getting an html column wasn't intended(although getting an image/png column was the intention in #1077)

So the idea as I proposed is to remove text/html from here:

postgrest/src/PostgREST/Types.hs

Lines 61 to 63 in ea97055

	-- | ContentTypes that can get a raw/unwrapped response
	rawContentTypes :: [ContentType]
	rawContentTypes = [CTOctetStream, CTTextPlain, CTTextHtml]

And instead let the user specify other media types on the config option I mentioned.

Also adding tests with the Accept header that chrome/firefox send would be good so this kind of mistakes don't happen again.

We might do a quick release for v6.0.1 once this is fixed.