iTunes refuses to stream music from 127.0.0.1

[zooko]

If I ask iTunes on Mac OS X to stream music from my local Tahoe-LAFS web gateway (telling it to connect to 127.0.0.1), it silently ignores my request. But if I ask it to connect to localhost then it works. I'm not sure if there's anything Tahoe-LAFS can do to help users deal with this. Possibly adjust any docs to suggest connecting to localhost instead of connecting to 127.0.0.1. If there isn't anything we can do then we'll just close this ticket as "invalid".

[davidsarah]

The web gateway could redirect to the localhost URL. However, that's only practical if the gateway knows that it is being contacted on 127.0.0.1. It is possible that iTunes is sending a Host: 127.0.0.1 HTTP header. (Although ​RFC 2616 requires the Host header to always be sent for HTTP 1.1, by my reading it is ambiguous whether it should be 127.0.0.1 or empty in this case.) Can you have a look what headers iTunes is sending?

Does connecting to other decimal IPv4 addresses work?

[warner]

FYI, to print the inbound HTTP request headers to twistd.log, find the appropriate render_ method (probably allmydata.web.filenode.FileNodeHandler.render_GET​) and add something like this:

for k,v in req.requestHeaders.getAllRawHeaders():
    print "H", k, v

Also, req.getHeader("host") will fetch a single header (or None if there was no header of that name).

[davidsarah]

Assigning to Zooko the task of getting the HTTP headers sent by iTunes on Mac OS X.

[zooko]

Hm, I pointed iTunes at an mp3 file on tahoe-lafs, and iTunes gave some error message to the effect that the server had disconnected. So then I edited the tahoe-lafs source code to print out headers as suggested by Brian in comment:3 and tried again, and this time it worked and started playing the song. It works whether you specify "localhost" or "127.0.0.1". I restarted iTunes and tried again (using "127.0.0.1") and it worked again. I've upgraded iTunes a couple of times since I opened the initial bug report, so perhaps the problem I reported initially has since been fixed in iTunes.

Also I've upgraded Tahoe-LAFS to v1.8.1 which has good support for range requests in downloads of immutable files. Perhaps iTunes seeks around in an mp3 when preparing to play it and the earlier version of Tahoe-LAFS that I was using when I opened this ticket confused iTunes by its inefficient handling of range-requests.

The headers sent by iTunes are:

2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H X-Audiocast-Udpport ['59397']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H Connection ['close']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H Accept ['*/*']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H User-Agent ['iTunes/10.1.1 (Macintosh; Intel Mac OS X 10.6.5) AppleWebKit/533.19.4']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H Host ['localhost:3457']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H Cache-Control ['no-cache']
2010-12-29 00:13:36-0700 [HTTPChannel,2,127.0.0.1] rG H Icy-Metadata ['1']

Sorry about that irreproducible failure about my current version of iTunes reporting the server as having disconnected -- please disregard unless I can reproduce it.