Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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!

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
interesting. good follow-up on your own question. – quack quixote Nov 8 '09 at 22:57
interesting indeed - but this was a question for stack after all! ;) – cregox Jan 10 '11 at 8:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.