Fork me on GitHub
#yada
<
2016-05-06
>
mccraigmccraig10:05:22

@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 ?

malcolmsparks11:05:28

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

mccraigmccraig11:05:05

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

mccraigmccraig11:05:24

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

malcolmsparks11:05:27

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

malcolmsparks11:05:33

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

mccraigmccraig11:05:55

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

mccraigmccraig11:05:18

my code was all run on #C0702A7SB simple_smile

mccraigmccraig11:05:39

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

malcolmsparks11:05:49

are you sending an Accept header in your client code?

mccraigmccraig11:05:56

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

malcolmsparks11:05:13

and yes, I'm sending an Accept header

malcolmsparks11:05:56

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

mccraigmccraig11:05:59

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

malcolmsparks11:05:34

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

malcolmsparks11:05:52

then we can dig a bit deeper

malcolmsparks11:05:08

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

malcolmsparks11:05:42

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 :)

malcolmsparks11:05:12

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

malcolmsparks11:05:27

And a video intro is in the pipeline

malcolmsparks11:05:34

Gosh, so much to do still

mccraigmccraig11:05:26

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

mccraigmccraig11:05:59

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

malcolmsparks11:05:33

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

mccraigmccraig11:05:00

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

mccraigmccraig11:05:34

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 ?

malcolmsparks11:05:08

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

mccraigmccraig11:05:45

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

malcolmsparks11:05:59

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.

malcolmsparks11:05:18

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] |

malcolmsparks11:05:29

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

mccraigmccraig11:05:26

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

mccraigmccraig11:05:51

(rfc2616 rather than rfc7231)

malcolmsparks11:05:23

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

malcolmsparks11:05:29

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)}))))

malcolmsparks11:05:09

@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)

malcolmsparks11:05:36

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

mccraigmccraig11:05:52

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

malcolmsparks11:05:21

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

malcolmsparks11:05:47

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

mccraigmccraig11:05:36

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

malcolmsparks12:05:34

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

malcolmsparks12:05:52

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

richiardiandrea19:05:57

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