liberator

2016-02-11T11:53:37.000004Z

The project dependency coordinate on the docs page is out of date: http://clojure-liberator.github.io/liberator/ It should be 0.14.0 now

ordnungswidrig 2016-02-11T12:49:31.000005Z

Thanks, that’s correct.

ordnungswidrig 2016-02-11T12:49:57.000006Z

@rickmoynihan: woud you mind file a quick issue at github?

ordnungswidrig 2016-02-11T13:08:32.000009Z

thanks

2016-02-11T14:29:24.000010Z

no worries

2016-02-11T14:30:30.000011Z

I'm trying to debug this liberator resource:

2016-02-11T14:31:33.000013Z

Basically it does some content neg on a file on the filesystem and presents the file for download

2016-02-11T14:35:47.000014Z

Now in my tests the file (if it exists) always comes out with the set content type... But when I call the route for real something seems to be setting the content-type to application/octet-stream... I'm guessing its a middleware somewhere; but I've been through pretty much every middleware and they all seem to be doing whats expected. At first I thought it was wrap-content-typebeing included via wrap-defaults doing the wrong thing... but when I debugged it in cider it returns the correct content type... I'm not sure where else to look

2016-02-11T14:39:23.000015Z

If I call the resource at the repl or in my tests it looks like too works

2016-02-11T14:40:32.000016Z

I'm using ring.server.standale... so maybe something in jetty is stomping on it

ordnungswidrig 2016-02-11T15:43:41.000017Z

You can always call your resource as a ring handler function:

ordnungswidrig 2016-02-11T15:44:56.000018Z

((download-file „dir“ „file“) {:request-method :get :uri „/„ :headers {„Accept“ „*/*“}}

2016-02-11T16:18:44.000019Z

@ordnungswidrig: yeah I've tried that and it works... I think there's a bug in ring.... When you return a :body with a File in it, it stomps on your content-type and sets it to application/octet-stream

2016-02-11T16:18:57.000020Z

just about to drill into ring to see where it happens

2016-02-11T16:19:40.000021Z

e.g. This ring handler: (ANY "/fooo" req {:status 200 :headers {"Content-Type" "application/csv"} :body (io/file "/tmp/foo.csv")}) will be octet-stream

2016-02-11T16:20:51.000023Z

I get the same behaviour on both http-kit and jetty

ordnungswidrig 2016-02-11T16:21:22.000024Z

Which middleware do you use?

2016-02-11T16:22:01.000025Z

I don't think its the middleware pipeline... I've ran a debugger over them and it's what I've set

ordnungswidrig 2016-02-11T16:23:22.000026Z

So the routes are directly run with the jetty adapter? Weird

2016-02-11T16:24:41.000027Z

not actually tried that... but the middlewares I have set up are returning what I want

2016-02-11T16:25:40.000028Z

just gonna try that to be sure though

2016-02-11T16:37:42.000029Z

ok you're right this does work: (run-server (fn [req] {:status 200 :headers {"Content-Type" "text/csv"} :body (<http://clojure.java.io/file|clojure.java.io/file> "/tmp/foo.nt")}) {:port 12345} )

2016-02-11T16:37:55.000030Z

must be one of the middlewares

ordnungswidrig 2016-02-11T18:33:03.000031Z

looks like a bug in one of them...

2016-02-11T22:23:32.000033Z

I was accidentally including the deprecated wrap-file-info middleware - my mistake