@malcolmsparks: just noticed that my yada responses from resources with :produces #{"application/json"} are not having Content-Type headers set... is that expected behaviour ? do i need to set a Content-Type header manually ?

really? do you mean the Content-Type doesn't have charset on it or is it missing altogether?

it's missing altogether... seems to be the case with all our resources - i never noticed before, because our client mostly just assumes JSON

it could, of course, be that we are doing something dumb in our yada invocations

hmm. that's odd - I'll take a look

sorry to miss your talk the other night - how did it go?

ok i think - i'm rubbish at judging - some people said they found it interesting and/or useful

my code was all run on #C0702A7SB

here's a simple resource which isn't returning a content-type header https://www.refheap.com/118780

are you sending an Accept header in your client code?

and the associated defresource macro https://www.refheap.com/118779

hmm no

fwiw this works: https://github.com/juxt/mksmarthack/blob/master/src/mksmarthack/core.clj#L51

and yes, I'm sending an Accept header

I think it might be a bug in yada where if you don't send an Accept header (which implies /), the Content-Type isn't set

ah, hold on - we are sending Accept */*

Can you try with curl with -H Accept:application/json - just to rule out that as a possibility

then we can dig a bit deeper

I've raised https://github.com/juxt/yada/issues/93 in the meantime, just as a placeholder

https://github.com/juxt/yada/issues/91 is also related to conneg so I'm gearing up for a proper deep dive into conneg next week (I've reserved a few hack days :)

I also need to write up yada's OAuth2 support which has been working well on a few projects

And a video intro is in the pipeline

Gosh, so much to do still

ok, that's interesting - a simple curl request, even with Accept: */* gives me back a Content-Type

so there is some feature of the ajax request which is causing the loss of the Content-Type

can you grab the request headers from the dev console and paste here?

Accept:application/json
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:localhost:8080
Referer:
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2549.0 Safari/537.36

ah, i was looking at a HEAD request @malcolmsparks - i get a Content-Type with GET... should not HEAD return the same headers as GET though ?

ah, no.

hang on while I find some biblical passages to start throwing at you...

lol

i took from s9.4 of https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html that they should have the same headers

https://tools.ietf.org/html/rfc7231#section-4.3.2: The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted.

But 3.3 says payload headers are | Content-Length | Section 3.3.2 of [RFC7230] | | Content-Range | Section 4.2 of [RFC7233] | | Trailer | Section 4.4 of [RFC7230] | | Transfer-Encoding | Section 3.3.1 of [RFC7230] |

but not Content-Type - so there's something wrong with yada

hah, and i was looking at an obsolete version of the spec too

(rfc2616 rather than rfc7231)

yeah, rfc2616 is obsolete - those other httpbis ones are much better (rfc7231-723x)

The logic in yada.interceptor does look right to me - it's saying that if the resource produces a media-type, and there's a HEAD method, then add the content-type header

clojure
(when-let [x (:media-type produces)]
                     (when (or (= method :head) body)
                       (let [y (:charset produces)]
                         (if (and y (= (:type x) "text"))
                           {"content-type" (mt/media-type->string (assoc-in x [:parameters "charset"] (charset/charset y)))}
                           {"content-type" (mt/media-type->string x)}))))

@mccraigmccraig: do you have your own build of yada? can you git clone it and lein install a local version (perhaps with a modified project.clj version)

it would be useful to know which conditional branches are being followed in your use case - i.e. add some printlns!

@malcolmsparks: yeah, i can ... not til next week though... i've got a release to deliver now

Understood. Let's chat next week if you can wait until then

I will be track it as an issue - I'll be reviewing this area of yada soon

yep, i can - the lack of a content-type header is causing me no problems right now - my client knows it wants application/json

and it might just be with HEAD too - that's an edge case in my book

(not that we shouldn't fix edge cases but you know what i mean...) - good luck with the release

thanks

one question, for async responses, which "async" object can I return for a :response? can it be a channel?