Is it possible to use ring.util.http-response/header to set the content-type of the response?

Something like this:

(header (ok csv-string) "Content-Type" "text/csv; charset=utf-8")

That has no effect for me; I still get a Content-Type: application/json response, and the CSV string is wrapped in quotes to make it valid JSON

you can bypass the ring-middleware-format encoding by assoc'ing the :compojure.api.meta/serializable? true to request.

I think thats not documented well anywhere :(

could be in the public api, something like (raw-response (ok ...))?

ah, and the value should be false here.

@ikitommi Did you mean to assoc the 'serializable?' key with the respose, and not the request? That's what makes sense to me:

(PUT "/analysis/:date.csv"
                      [date request]
                      :return String
                      :summary "Generates a report for the given date and returns it"
                      (->> [["Date"], [date]]
                           write-csv
                           ok
                           (#(assoc % :compojure.api.meta/serializable? false))))

But, that has no effect. That leads to a couple more questions, that I can't find docs for: - Where to I add a parameter to make the request object available in the handler? - How do I pass a modified request object back to compojure-api? Is this is standard ring middleware? - Which lib defines raw-response? I'm having trouble searching for it...

Ah, I discovered https://github.com/metosin/compojure-api/issues/61, that might point the way

- Where to I add a parameter to make the request object available in the handler? Should work same as in normal Compojure always

That is: (PUT "/analysis/:date.csv" req ...), I don't think you can at the same time use path destructuring and get the full request

Ah, ok, I just had a mistake in the request destructing, I actually can access the entire request object.

But, looking that a test linked from that issue, it looks like I need to assoc compojure.api.meta/serializable? to the response, not the request

Oh, ok, I found https://github.com/metosin/compojure-api/commit/73a1c16b5b1e7692bf95471f06e66b41ae5091f9. It looks like I'm supposed to add a coercer to compojure-api's existing coercers, and then indicate that I want CA to use that...

Ah, :compojure.api.meta/serializable? false didn't work because you also had :return String

If you want to return raw response you should not use :return

This should work without custom coercer

Boom! You rock @juhoteperi 🍻 , thanks for the extra eyes

there is no raw-response at the moment, but I think there should. Would just assoc the :compojure.api.meta/serializable? to false...

And we should also document and preferably check at compile/run-time that :return doesn't break raw-response

Hey guys, me again. I'm curious as to what the sanest way to make endpoints with logic that branches on the accept header. For example, if you send a GET to .../users/jeff with an accept of "text/html", I want to return the page, while a request of "application/json" should return Jeff's information as a json object. Likewise, POSTing to the url should either return the updated page or json object, respectively. I was handling this before by making multiple routes, which would return nil for a mime type it didn't handle, which caused compojure to roll onto the next one. However, now that I'm trying to use compojure-api to validate my api and generate documentation, this approach is causing problems. multiple routes to the same endpoint step on each other for documentation, and posting with different types means that only one of :body-params and :form-params is populated, which means that if the json route is evaluated first for an application/x-www-form request, for example, it returns an error about :body-params being empty instead of nilling out and rolling onto the route that would properly return a text/html response