I've been troubleshooting with Sonos reps and we determined that Astaro's Web Filtering capability is the culprit. Sonos' Songza service does not function with Web Filtering enabled, functions perfectly with Web Filtering disabled.
Here are the details:
On Thu, Nov 15, 2012 at 11:14 AM, Perry S <support@sonos.com> wrote:
Scott,
Just wanted to give you a status on what we saw yesterday and where we are at.
Here is what is happening:
Sonos on Songza-
Sonos Zoneplayer communicates with Songza by sending an http GET request. That is responded to correctly in your set up.. (this opens the stream and starts us to ready to playback)
- Sonos Zoneplayer then sends a series of http Get requests, with a `range header specified. (this is the mechanism we use to ask for parts of a file, and allows the sender to send the `asked for part of the file-.. (this is how we obtain embedded metadata information in the stream.).
- The correct response, to the Get requests with `range header, is a 206- Partial Content, along with the parts of the content asked for in the request.
What we see on your network (in our log files and packet captures taken from the Zoneplayer, is the Get requests with range headers are being responded to with a 200- essentially the entire file. (as if we did not ask for partial content).
That is what causes us to throw the error - ` .corrupt file or .file formatted incorrectly ..-- and in the internal logs, `Bad Http Header. (because the header info we expect is `partial content..
Possibilities of root cause:
1. Songza is responding to our GET REQUEST Partial Content, incorrectly with a http: 200 (and sending full content)- and ignoring the partial content header.
I do not believe this is happening , as every Sonos user on Songza would have this problem.
2. We are sending Get Request- Partial Content, the header information is being intercepted, stripped altered, and Songza receives and responds to a full content Get Request.
Songza responds correctly for what they receive (response= 200) , but what the Zoneplayer actually sent was a Partial Content Request
3. We are sending Get Request-Partial Content, Songza receives that request ,and responds correctly with 206 Partial Content header (correctly), but what we get back is a 200, which we do not expect, and throw the error.
There is something between the Zoneplayer and the endpoint (Songza) that is not supporting http Range Header (partial content)
I am reviewing the packet captures to see if I can find what this is exactly
Things that we are looking for is anything that is doing caching, like a Squid server, or other proxy servers in the path.
I am providing all of this information as it may help you track this down as we continue to help.
If there is nothing you can determine within your control to be the cause- with this information, taking it to your ISP is probably a good thing to do.. They might know exactly what this (maybe).
I will also provide the packet captures I have, if that helps you or your ISP.
Also- are there any setting on the router that you can identify that might deal with caching, http headers, -- anything?
In summary- we are not getting responses back that are expected, and the responses we do get back indicate that our http requests for partial content (range header)- is being ignored.
There is nothing I can fix on our side- but I can help you to find what is causing this.
Today, I am digging into the network traces taken, and researching reported problems around the use of http partial content, to see if perhaps others ran into similar issues with other applications. Maybe that will show us a solution.
Let me know if you have any questions, any ideas, and keep me informed of any progress you make in investigating what you can, based on the information I provided.
I will continue to investigate too, and will get back to you as soon as I have something, or at least touch base with your tomorrow with a status.
Here are the details:
On Thu, Nov 15, 2012 at 11:14 AM, Perry S <support@sonos.com> wrote:
Scott,
Just wanted to give you a status on what we saw yesterday and where we are at.
Here is what is happening:
Sonos on Songza-
Sonos Zoneplayer communicates with Songza by sending an http GET request. That is responded to correctly in your set up.. (this opens the stream and starts us to ready to playback)
- Sonos Zoneplayer then sends a series of http Get requests, with a `range header specified. (this is the mechanism we use to ask for parts of a file, and allows the sender to send the `asked for part of the file-.. (this is how we obtain embedded metadata information in the stream.).
- The correct response, to the Get requests with `range header, is a 206- Partial Content, along with the parts of the content asked for in the request.
What we see on your network (in our log files and packet captures taken from the Zoneplayer, is the Get requests with range headers are being responded to with a 200- essentially the entire file. (as if we did not ask for partial content).
That is what causes us to throw the error - ` .corrupt file or .file formatted incorrectly ..-- and in the internal logs, `Bad Http Header. (because the header info we expect is `partial content..
Possibilities of root cause:
1. Songza is responding to our GET REQUEST Partial Content, incorrectly with a http: 200 (and sending full content)- and ignoring the partial content header.
I do not believe this is happening , as every Sonos user on Songza would have this problem.
2. We are sending Get Request- Partial Content, the header information is being intercepted, stripped altered, and Songza receives and responds to a full content Get Request.
Songza responds correctly for what they receive (response= 200) , but what the Zoneplayer actually sent was a Partial Content Request
3. We are sending Get Request-Partial Content, Songza receives that request ,and responds correctly with 206 Partial Content header (correctly), but what we get back is a 200, which we do not expect, and throw the error.
There is something between the Zoneplayer and the endpoint (Songza) that is not supporting http Range Header (partial content)
I am reviewing the packet captures to see if I can find what this is exactly
Things that we are looking for is anything that is doing caching, like a Squid server, or other proxy servers in the path.
I am providing all of this information as it may help you track this down as we continue to help.
If there is nothing you can determine within your control to be the cause- with this information, taking it to your ISP is probably a good thing to do.. They might know exactly what this (maybe).
I will also provide the packet captures I have, if that helps you or your ISP.
Also- are there any setting on the router that you can identify that might deal with caching, http headers, -- anything?
In summary- we are not getting responses back that are expected, and the responses we do get back indicate that our http requests for partial content (range header)- is being ignored.
There is nothing I can fix on our side- but I can help you to find what is causing this.
Today, I am digging into the network traces taken, and researching reported problems around the use of http partial content, to see if perhaps others ran into similar issues with other applications. Maybe that will show us a solution.
Let me know if you have any questions, any ideas, and keep me informed of any progress you make in investigating what you can, based on the information I provided.
I will continue to investigate too, and will get back to you as soon as I have something, or at least touch base with your tomorrow with a status.