0.9.1 downloads instead of displays

[kanwei]

I've got a pretty simple setup:

(def app (-> all-routes
             (middleware/app-handler :session-options {:cookie-name "dd-session"
                                                      :store (cookie-store {:key (:cookie-key configs)})})
             middleware-json/wrap-json-body
             middleware-json/wrap-json-response
             jsonp/wrap-json-with-padding
             middleware-json/wrap-json-params
             wrap-params))

However, after upgrading to 0.9.1 webpages get downloaded instead of displayed as html.

[yogthos]

One big change in 0.9.1 is that the app-handler uses ring-defaults now. The site-defaults configuration is used when none is specified. This might be conflicting with your middleware.

As a side note, the preferred way to add middleware to app-handler is by putting it in a vector using the :middleware key. This way the middleware will be applied after the default middleware.

[yogthos]

could you try initializing the handler as follows and see if you still get the same issue:

(def app
  (app-handler
   [all-routes]
   :session-options {:cookie-name "dd-session"
                     :store (cookie-store {:key (:cookie-key configs)})}
   :middleware
   [middleware-json/wrap-json-body
    middleware-json/wrap-json-response
    jsonp/wrap-json-with-padding
    middleware-json/wrap-json-params
    wrap-params]))

[yogthos]

@kanwei are you still seeing the issue, or can we close it?

[kanwei]

Nope, still doing the same thing..

[yogthos]

I can't seem to reproduce the issue using the luminus template, could you possibly make a sample project that exhibits it to help with debugging.

[adamneilson]

I have a very similar issue. After running lein ancient on my Luminus based project I discovered that lib-noir was out of date and upgraded from 0.8.3 to 0.9.4. After doing this I discovered that none of the POSTs worked on my site as 0.9.4 seemed to switch Ring-Anti-Forgery on by default and I was getting a <h1>Invalid anti-forgery token</h1> response without any logging on the server-side.

I figured the added security was a good thing™ and so set about adding {% csrf-token %} tags to some of the forms on the site for testing.

Having done this I have found that the forms submit, they are accepted through the anti-forgery filter and get correctly forwarded on to the API but on the return journey the browser downloads the response rather than rendering it. As though a content-disposition header has been added or maybe Content-Type header has been stripped?

Rolling back to 0.8.3 makes this problem go away.

Here's my app-handler...

(def app (app-handler
             ;;  application routes 
             [home-routes
              other-routes
              ;<<===== LASTLY ======>>
              app-routes]
           ;; add custom middleware here
           :middleware [middleware/log-request
                        middleware/template-error-page
                        ; force SSL when we're running from production
                        middleware/with-force-ssl
                        ; are we on speaking terms with this IP?
                        middleware/block-ip-address?]

           ;; add access rules here
           :access-rules []
           ;; serialize/deserialize the following data formats. Available formats:
           ;; :json :json-kw :yaml :yaml-kw :edn :yaml-in-html
           :formats [:json-kw :edn]
           :session-options {:cookie-name "my-app"
                             :store (ring.middleware.session.cookie/cookie-store)}))

[yogthos]

The handler changed a bit to use ring-defaults to initialize the stock middleware, here's what it looks like currently. The custom middleware has now been moved to its own nsamespace as well here. Apps created using the latest template don't appear to exhibit the issue, so it does sound like the problem is with how the middleware is initialized.

[devasiajoseph]

Not sure whether related to this, but after upgrading to 0.9.4 and when I return (status 200 "Hello world") (status is from noir.response) It prompts me to download the content. Shouldn't it be displaying "Hello world"? I see the content type returned is "octet-stream". I am using luminus template. What am I missing?

[yogthos]

It sounds like all the issues relate to content type not being set correctly. Are you using the latest version of the template. When I create a new project using lein new luminus test-app I'm not able to reproduce this issue. Are you experiencing this a problem with the latest version of lein and the luminus template?

[devasiajoseph]

Yes, I tested this by creating a new project lein new luminus test-app. The function looks like this (defn test-page [] (response/status 200 "Hello world")) response is from [noir.response :as response]. Lein version is 2.5.0

[yogthos]

It looks like you have to set the content type explicitly with ring-defaults:

(response/content-type "text/plain; charset=utf-8" (response/status 200 "Hello world"))

[kanwei]

Is this an issue with ring-defaults then? Seems a bit insane to have this not working by default ;)

[yogthos]

I'm just looking through what it's doing, and it looks to be setting content-type wrapper to true for site-defaults here. Perhaps the behavior changed there. Have to investigate further.

Note that returning a string will work as expected:

(GET "/" [] "Hello world")

However, when you use response/status the result becomes a map, and since the map has no content type set, it appears to default to one that's not very useful.

[yogthos]

This is where the octet-stream content type comes from:

(defn content-type-response
  "Adds a content-type header to response. See: wrap-content-type."
  {:arglists '([response request] [response request options])
   :added "1.2"}
  [resp req & [opts]]
  (if (get-header resp "Content-Type")
    resp
    (let [mime-type (ext-mime-type (:uri req) (:mime-types opts))]
      (content-type resp (or mime-type "application/octet-stream")))))

https://github.com/ring-clojure/ring/blob/a39825e6d1050f915ebffefaf8c3ae4ac1434adf/ring-core/src/ring/middleware/content_type.clj#L14

[devasiajoseph]

Another issue is, I am not able to serve cache manifest file in resources/public. I see the extension "appcache" is mapped to "text/cache-manifest" in https://github.com/ring-clojure/ring/blob/master/ring-core/src/ring/util/mime_type.clj#L10 . I see (wrap-file-info) https://github.com/ring-clojure/ring/blob/master/ring-core/src/ring/middleware/file_info.clj#L56 is supposed to be handling content types. Currently I am using lib-noir content type setting to serve this file. Wondering anyone else had this issue?