iTunes refuses to stream music from 127.0.0.1 #921

New Issue

zooko · 2010-01-20T17:29:50Z

zooko commented

2010-01-20 17:29:50 +00:00

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".

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".

zooko added the

labels 2010-01-20 17:29:50 +00:00

zooko added this to the undecided milestone 2010-01-20 17:29:50 +00:00

zooko changed title from ~~iTunes and refuses to stream music from 127.0.0.1~~ to iTunes refuses to stream music from 127.0.0.1

2010-01-20 17:30:00 +00:00

davidsarah commented

2010-01-22 01:13:36 +00:00

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?

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](http://tools.ietf.org/html/rfc2616#section-14.23) 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 commented

2010-01-22 07:23:56 +00:00

FYI, to print the inbound HTTP request headers to twistd.log, find the appropriate render_ method (probably [allmydata.web.filenode.FileNodeHandler.render_GET]source:src/allmydata/web/filenode.py#L164) 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).

FYI, to print the inbound HTTP request headers to twistd.log, find the appropriate `render_` method (probably [allmydata.web.filenode.FileNodeHandler.render_GET]source:src/allmydata/web/filenode.py#L164) 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 commented

2010-04-03 23:45:33 +00:00

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

zooko was assigned by tahoe-lafs

2010-04-03 23:45:33 +00:00

zooko commented

2010-12-29 07:57:36 +00:00

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:74889 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.

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:74889](/tahoe-lafs/trac-2024-07-25/issues/921#issuecomment-74889) 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.

zooko added the

cannot reproduce

label 2010-12-29 07:57:52 +00:00

zooko closed this issue

2010-12-29 07:57:52 +00:00

Sign in to join this conversation.