We hebben een probleem bij een van onze producten (web-based applicatie) waarbij klanten melden dat een pagina waarop mp3's afgespeeld worden 2 of 4 minuten lijken te hangen. Daarna wordt het audiobestand alsnog afgespeeld. Deze klanten zijn allemaal basisscholen, en die gebruiken vaak KlikSafe. Daarmee gaat hun internetverkeer via Squid.
In een poging het probleem te reproduceren heb ik Squid geïnstalleerd (2.7.STABLE9 op een verder kale Debian 7) in ons netwerk en die als proxy ingesteld in m'n browser, en ja hoor: mp3's laten 2 minuten op zich wachten nadat Squid ze de eerste keer heeft gecachet. Dat wil zeggen dat de eerste keer het bestand met een 200 opgehaald wordt (direct), maar de keren daarna duurt het ongeveer 240 seconden bij veel klanten, of ongeveer 120 seconden (bij ons).
In de browser is de status een 304 maar hij blijft dus 2 minuten op (pending) staan nadat de pagina verder geladen is.
Een screenshot is misschien duidelijker:

Dit gedrag snap ik niet. Ik kan niet echt vinden waarom Squid dit doet. In access.log ziet dat er zo uit (ik heb het domain even gefingeerd met domain):
Als ik het verkeer niet via squid laat lopen gaat het dus prima, en als ik met tail -f access.log volg, dan zie ik dat het request direct binnenkomt. Op de één of andere manier lijkt Squid er dus 2 minuten over te doen om dat ding uit de cache te halen, maar omdat het steeds zo goed als 120 seconden (meestal een paar ms meer of minder), en bij de proxy van KlikSafe 240 seconden is, lijkt het een soort timeout te zijn?
Tevens gaat het alleen mis bij de mp3's in dit geval maar dus niet bij afbeeldingen of scripts ofzo.
Heeft iemand een idee waar ik dit moet zoeken? Ik kan er niet veel over vinden bij Google. Het lijkt alsof hier ongeveer hetzelfde probleem wordt beschreven, maar een antwoord zie ik er niet tussen en het moet eigenlijk ook opgelost worden zonder aan Squid te komen omdat we geen invloed hebben op proxyservers van een derde partij.
In een poging het probleem te reproduceren heb ik Squid geïnstalleerd (2.7.STABLE9 op een verder kale Debian 7) in ons netwerk en die als proxy ingesteld in m'n browser, en ja hoor: mp3's laten 2 minuten op zich wachten nadat Squid ze de eerste keer heeft gecachet. Dat wil zeggen dat de eerste keer het bestand met een 200 opgehaald wordt (direct), maar de keren daarna duurt het ongeveer 240 seconden bij veel klanten, of ongeveer 120 seconden (bij ons).
In de browser is de status een 304 maar hij blijft dus 2 minuten op (pending) staan nadat de pagina verder geladen is.
Een screenshot is misschien duidelijker:

Dit gedrag snap ik niet. Ik kan niet echt vinden waarom Squid dit doet. In access.log ziet dat er zo uit (ik heb het domain even gefingeerd met domain):
code:
1
| 1381505468.089 0 192.168.150.104 TCP_IMS_HIT/304 354 GET http://domain/media/57733/c2a.mp3 - NONE/- audio/mpeg |
Als ik het verkeer niet via squid laat lopen gaat het dus prima, en als ik met tail -f access.log volg, dan zie ik dat het request direct binnenkomt. Op de één of andere manier lijkt Squid er dus 2 minuten over te doen om dat ding uit de cache te halen, maar omdat het steeds zo goed als 120 seconden (meestal een paar ms meer of minder), en bij de proxy van KlikSafe 240 seconden is, lijkt het een soort timeout te zijn?
Tevens gaat het alleen mis bij de mp3's in dit geval maar dus niet bij afbeeldingen of scripts ofzo.
Heeft iemand een idee waar ik dit moet zoeken? Ik kan er niet veel over vinden bij Google. Het lijkt alsof hier ongeveer hetzelfde probleem wordt beschreven, maar een antwoord zie ik er niet tussen en het moet eigenlijk ook opgelost worden zonder aan Squid te komen omdat we geen invloed hebben op proxyservers van een derde partij.
Saved by the buoyancy of citrus