[8.285][QUESTION][ANSWERED] Web Filtering Question

More background -

Transparent proxy enabled.
Exception added -
 Authentication / Caching / Antivirus / Extension blocking / MIME type blocking / URL Filter / Content Removal / SSL scanning / Certificate Trust Check / Certificate Date Check

 Matching these URLs:
  ^https?://[A-Za-z0-9.-]*listen.vo.llnwd.net/
  ^https?://[A-Za-z0-9.-]*rhapsody.com/
  ^https?://[A-Za-z0-9.-]*rhap.com/

It does work when I add "direct.rhapsody.com" to the Advanced Server exceptions list.

Can you try to use these URLs in a Browser just to check if they use some redirects to dynamic URLs? If this would be the case, the Exception would be superflous.

I have tried the links through the browser and just gives an unrelated message.  The fact that adding "direct.rhapsody.com" to the server skip list on the advanced tab makes it work and the fact that direct.rhapsody.com matches the regex and shows in the log with the exceptions listed implies that it is the problematic site.

Adding all the exceptions in the "Exceptions" tab seams like it does a bit less then adding the server to the exception list in the advanced tab.

This used to work for me with only the exceptions in the Exceptions tab, but I don't know how long ago or what else has changed.  I will rebuild with the production ISO and see if that acts the same.  If so, I will close this here and open a general question.

I think brk knows what I'm about to say, but, just so others don't get confused: the 'Transparent mode skiplist' really only uses IP addresses instead of URLs.  That is to say, a DNS Host definition with direct.rhapsody.com resolves to 66.150.171.142 in that list.  When the proxy is in transparent mode, it sees that your browser is asking to connect to 66.150.171.142, and so "skips" that particular request - it won't even show up in the log file.

@brk - Is there anything unusual in your Firewall log at the same time as your attempts above?  Is there anything in the httpproxy log between those four entries above -something blocked that might have been a part of the conversation with 66.150.171.142? 

Cheers - Bob
PS Actually, that should be ^https?://[A-Za-z0-9.-]*rhapsody[/B].com/ to be precise, but it works because . matches to any single character.

Fun with wireshark...  This is wireshark running on the machine running the rhapsody client.  

Case 1 - PASS - direct.rhapsody.com added to the transparent proxy skip host list on the advanced tab.  Client is requesting data, says will accept gzip, server appears to be responding with compressed data.

--------------------
POST /metadata/services/RhapsodyDirectMetadata HTTP/1.1

CONNECTION: close

ACCEPT-ENCODING: gzip

HOST: direct.rhapsody.com

USER-AGENT: Linux UPnP/1.0 Sonos/16.5-47300b (PCDCR)

CONTENT-LENGTH: 363

CONTENT-TYPE: text/xml; charset="utf-8"

SOAPACTION: "urn:kani#getProgrammedStations"



0100********401342HTTP/1.1 200 OK

Date: Wed, 07 Dec 2011 04:01:18 GMT

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=utf-8

Connection: close

Cache-Control: private

Content-Encoding: gzip

Transfer-Encoding: chunked



3818

...........}ks.H..w..r....."ER/...C.[.m.^Q....76.D......@4....,...jSZrB..q.$.@...8.......8R7.e.M..K...E..o.0....".......Efuj..g......(....Is..k.....o.q../.E..9.'......8|.........?........J.]....|z.9...c.?.l.j.b....1..l\..lph...c.......



Case 2 - This case failed.  Same stream, but this time with the IP address of the server removed from the advanced tab "skip transparent mode" and the regular expression added to the exclusion tab. The exclusions are being honored per the web filter log.   This time the server is responding with uncompressed data.

POST /metadata/services/RhapsodyDirectMetadata HTTP/1.1

CONNECTION: close

ACCEPT-ENCODING: gzip

HOST: direct.rhapsody.com

USER-AGENT: Linux UPnP/1.0 Sonos/16.5-47300b (PCDCR)

CONTENT-LENGTH: 363

CONTENT-TYPE: text/xml; charset="utf-8"

SOAPACTION: "urn:kani#getProgrammedStations"



0100********401342HTTP/1.1 200 OK

Date: Wed, 07 Dec 2011 03:59:37 GMT

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=utf-8

Cneonction: close

Transfer-Encoding: chunked

Connection: close



adc

2071000Nick DedinaForget the modern revision -- here are the real songs and artists that ruled the 1950s.
From Patti Page to Elvis the Pelvis, we tell the whole truth about th




Thoughts -
  1.  Sonos/Rhapsody client has a bug and can't handle the uncompressed data?  This seams unlikely, as the same symptoms appear on several different clients (Windows, iPhone, sonos hardare).  Of course, they probably share libraries...
  2.  Gzip or not doesn't matter, something else is getting messed up and I need to look at wireshark some more!
  2.  Why is the data coming back different in the two cases?  Is this allowed?  (I assume it is allowed, as the gzip is a request and not a requirement)

Furthur - looking at the headers using this page - 
   HTTP trace 1.06 (2002-10-14)

If the host is in the skiplist (or proxy is disabled) then the compression line is there
  [ 35] ACCEPT_ENCODING: gzip,deflate,sdch


Otherwise, the proxy is removing the gzip line.

So - this is likely a result of the way proxy servers work and a bug in the sonos client.

Is there a way to make proxy servers allow compressed data?  I understand it changes the challenge of scanning the data while it goes through the proxy..

I can't see if any request is going to another URL, but is this possibly related to the file type settings on the Anti-Virus tab?

Cheers -   Bob

Sorry for any short responses!  Posted from my iPhone.

I can't find any settings that change the way it works, other then the skip list. 

Google searches indicate that removing the compression line is very common for proxy servers. Google even has done tricks to test and add compression back. 

Is the only way the current http proxy can work is by removing the accept-encoding line?

Is the only way the current http proxy can work is by removing the accept-encoding line?

Yes. If the HTTP proxy wouldn't remove the Accept-Encoding request header, it would need to support for instance gzip compression. Right now it doesn't, so it simply removes that header.

Regards,
mlenk