2

This may seem like a question for stackoverflow, but bear with me:

I've built (most of) a DAAP server in Ruby, I've modeled its output on the mt-daapd server and consequently my test data is such that my server returns exactly* what the mt-daapd server does in the same situation.

(* The only difference is that my server adds the HTTP header 'Connection: close' which I can't for the life of my figure out how to stop - that is a question for stackoverflow)

I can go into more detail if required, but my problem is that while Songbird finds, attaches and reads my DAAP server perfectly, iTunes refuses to make anything other than the first '/server-info' request (see section '1. Server Info' of the unofficial spec). I should add that the mt-daapd share works perfectly, even while my daap server is rejected!

Obviously this could well be that iTunes doesn't like the fact that I'm sending 'Connection: close' header, but does anyone know anything more about the way iTunes 9.0.X expects its DAAP to be served? Or anywhere I can find out - short of peeling back layers of mt-daapd's code?

many thanks!

Improve this question

1 Answer 1

Reset to default
2

Turns out iTunes sends an unusual GET request, rather than the standard 'GET /path/to/whatever', iTunes (when browsing via DAAP) sends 'GET daap://ip.address/path/to/whatever'. Which is nice of it.

Improve this answer
2
  • 1
    interesting. good follow-up on your own question.
    – quack quixote
    Commented Nov 8, 2009 at 22:57
  • interesting indeed - but this was a question for stack after all! ;)
    – cregox
    Commented Jan 10, 2011 at 8:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .