Nieuwe afbeelding refreshed wel op Chrome, echter niet FF..

[gepebril]

Hallo,

Ik heb een eigenaardig iets. Ik probeer op een website de status van meerdere machines dynamisch weer te geven in een CSS "tabel" (hoeveelheid geheugen, vrije diskspace, cpu load etc). Dit doe ik door een Jquery elke 10 seconde uit te voeren en de waarden uit een MySQL database te lezen en deze in de CSS "tabels" te plaatsen. Dit werkt heel goed , zonder dat er iets verspringt wordt bij FF 9.01, Chrome 16.09....en IE8.0 alle gegevens van de CSS tabel netjes ververst.

Echter er is ook een image bij, welke ten minste elke minuut veranderd, niet van naam, wel van inhoud. Bij Chrome "out of the box" laadt hij elke 10 seconde de image, zichtbaar in, en als als het origineel op de website vervangen wordt verandert hij netjes mee, echter bij Firefox en IE veranderd de image nooit, alleen bij het drukken van F5(refresh). Ik vermoedde de cache bij FF, echter deze is op 0 Mbyte en ook bij IE is deze zo gezet dat de hele pagina steeds opnieuw ingeladen dient te worden.
Waar zou ik de oplossing dienen te zoeken voor dit "euvel" aan serverkant, of aan de client kant?

Hieronder de Jquery, welke ik gebruik.

code:

<script src="http://code.jquery.com/jquery-latest.js"></script>
<script>
 $(document).ready(function() {
   $("#active_window").load("response.php");
   var refreshId = setInterval(function()
   { $("#active_window").load('response.php?randval='+ Math.random());
   }, 10000); // In msec
   $.ajaxSetup({ cache: false });
 });
</script>

Albert

[RobIII]

Plaats de HTTP headers die de server stuurt voor de afbeelding(!) eens? Die kun je zien/analyseren met Firebug / IE F12 Dev.tools / Fiddler2 / Wireshark. Oh, en dan plaats (voor de zekerheid) ook maar even de request van de client.

[ Voor 19% gewijzigd door RobIII op 09-02-2012 21:46 ]

[gepebril]

@Roblll

Dank je wel voor je antwoord. Ik ga dat vanavond nog even uitzoeken.

Ik heb even een "expert" geraadpleegd, hij gaf me de volgende tip, indien de url van het plaatje http://www.hieppiep/images/plaatje_000.png is maak er dan van:
http://www.hieppiep/images/plaatje_000.png?date=1328822516
Waarbij de date bijvoorbeeld de epoch is. Zo fop je de meeste browsers, die denken namelijk dat het steeds een nieuw plaatje is
....... Nu alleen nog iets zoeken dat het netjes fade elke 10 sec ipv hard een nieuw plaatje inladen (ziet het opbouwen van boven naar beneden)

[ Voor 3% gewijzigd door gepebril op 09-02-2012 22:29 ]

[RobIII]

Wat die expert je niet heeft verteld is dat je daarmee onnodig je cache vervuilt* en dat dit een poor-man's anti cache oplossing is die je alleen als last resort gebruikt. Als je gewoon zorgt dat de server de juiste headers stuurt is dat wel zo netjes.

* Je cache is in de meeste gevallen gelimiteerd op X grootte; door allemaal onnodige images te cachen "duw" je andere (lees: oudere) items uit de cache waardoor je dus effectief je cache "vervuilt".
Als het gaat om een afbeelding van een paar bytes valt 't wel mee, als het gaat om wat forser spul tikt 't hard aan.

[ Voor 65% gewijzigd door RobIII op 09-02-2012 22:42 ]

[Room42]

Dat is natuurlijk niet handig omdat je dan elke 10 seconden het hele plaatje download. Dus ook als het plaatje op de server niet verandert is. Beetje zonde van de bandbreedte voor zowel jou als de bezoeker.

Zorg gewoon, zoals RobIII zegt, goed de headers toe.

[ Voor 11% gewijzigd door Room42 op 09-02-2012 22:33 ]

[Verwijderd]

De truuk vervuilt inderdaad je cache.

Maar is wel een snelle oplossing, zeker als je niet headers kan aanpassen.

Om het goed te doen moet je inderdaad een image handler maken die de juiste Expire headers stuurt. Bijvoorbeeld getimage.php en deze dan opnemen in de html die geinjecteerd wordt dus: <img src='getimage.php'>
Aangezien dat veel meer werk zou zijn leek me de random truuk nu afdoende.

En ook nog, als de parameter die wordt meegestuurd niet anders is als het plaatje niet veranderd worden er niet onnodige plaatjes gestuurd.


Groeten,
Bart

[RobIII]

Verwijderd schreef op vrijdag 10 februari 2012 @ 13:19:
Om het goed te doen moet je inderdaad een image handler maken die de juiste Expire headers stuurt.
...
Aangezien dat veel meer werk zou zijn leek me de random truuk nu afdoende.

Of je gebruikt je .htaccess of zet in de webserver zélf (bijv. IIS) de cache headers. Er hoeft geen code aan te pas te komen

Verwijderd schreef op vrijdag 10 februari 2012 @ 13:19:
En ook nog, als de parameter die wordt meegestuurd niet anders is als het plaatje niet veranderd worden er niet onnodige plaatjes gestuurd.

Hoe weet de client nou of 't plaatje gewijzigd is of niet? Er zal, volgens mij althans, altijd een request naar de server moeten als het plaatje server-side op een x-interval gewijzigd wordt. Of ik heb de topicstart verkeerd begrepen

[ Voor 8% gewijzigd door RobIII op 10-02-2012 17:50 . Reden: typo-fix ]

[gepebril]

RobIII schreef op donderdag 09 februari 2012 @ 21:33:
Plaats de HTTP headers die de server stuurt voor de afbeelding(!) eens? Die kun je zien/analyseren met Firebug / IE F12 Dev.tools / Fiddler2 / Wireshark. Oh, en dan plaats (voor de zekerheid) ook maar even de request van de client.

Ok, ik hoop dat ik het goede heb verzameld:

code:

Antwoordheadersbron bekijken
Cache-Control   private
Connection  Keep-Alive
Content-Encoding    gzip
Content-Length  818
Content-Type    text/html; charset=UTF-8
Date    Fri, 10 Feb 2012 16:03:48 GMT
Expires Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive  timeout=15, max=15
Pragma  no-cache
Server  Apache
Vary    Accept-Encoding
X-Powered-By    PHP/5.3.2-1ubuntu4.11

Verzoekheadersbron bekijken
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language nl,en-us;q=0.7,en;q=0.3
Connection  keep-alive
Cookie  PHPSESSID=d7cttgo2g613cnvuhog6fe2ar4
Host    213.155.3.25
Referer http://213.155.3.25/test/index.php?
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

code:

Of moet het dit zijn?
Antwoordheadersbron bekijken
Connection  Keep-Alive
Content-Encoding    gzip
Content-Length  47
Content-Type    text/html; charset=ISO-8859-1
Date    Fri, 10 Feb 2012 16:08:57 GMT
Keep-Alive  timeout=15, max=46
Server  Apache
Vary    Accept-Encoding

Verzoekheadersbron bekijken
Accept  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language nl,en-us;q=0.7,en;q=0.3
Connection  keep-alive
Cookie  PHPSESSID=d7cttgo2g613cnvuhog6fe2ar4
Host    213.155.3.25
Referer http://213.155.3.25/test/status_of_recorders.php
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

[ Voor 18% gewijzigd door gepebril op 11-02-2012 12:04 ]

[RobIII]

gepebril schreef op vrijdag 10 februari 2012 @ 17:06:
Ok, ik hoop dat ik het goede heb verzameld:

Heel mooi; en wat leid je daar zélf uit af? Je hebt informatie zat gehad om hier in ieder geval zelf al eens een gooi naar te doen i.p.v. het meteen weer in de groep te mikken

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime.

[gepebril]

@Roblll

Bedankt voor de feedback. Het euvel met te vaak refreshen heb ik omzeilt door ipv de epoch achter de url van de image te vervangen door de filesize. Daar alleen bij het veranderen van de filesize namelijk het plaatje ook is aangepast. ?filesize=xxxxxxx slim hè

Dit gaat vaak goed echter voor sommige plaatjes blijft hij herladen, vaag. I.i.g weer reden voor de mannen om een volgende release van FF en Chrome uit te brengen.

Moet zeggen dat ik het op dit moment belangrijker vindt dat het werkt dan dat ik per keer zijn cache met 15kbyte per keer vervuil. Maar dat komt doordat ik een aantal zaken met hoge prioriteit heb. Volgens mij is er een maximum aan cache geheugen. Eerlijk gezegd heb ik het idee dat ik wil, nog niet geïmplementeerd is in HTML, en dat waarschijnlijk pas in een later stadium gaat gebeuren en nu met allerlei foefjes op low-level niveau per browser kan manipuleren. Ik zie ontzettende complexe data specs voorbij komen van één of twee lagen lager in het OSI-model terwijl je natuurlijk iets wil als boven in je webpagina
set changepicture = smooth_transent
of als parameter meegeven in je stylesheet voor die betreffende div.

Misschien hadden de programmeurs naar de leus van de belastingdienst moeten luisteren, mooier kunnen we het niet maken, makkelijker wel

[ Voor 3% gewijzigd door gepebril op 10-02-2012 23:59 ]

[RobIII]

gepebril schreef op vrijdag 10 februari 2012 @ 23:53:
@Roblll

Bedankt voor de feedback. Het euvel met te vaak refreshen heb ik omzeilt door ipv de epoch achter de url van de image te vervangen door de filesize. Daar alleen bij het veranderen van de filesize namelijk het plaatje ook is aangepast. ?filesize=xxxxxxx slim hè

Niet echt; de kans op eenzelfde filesize voor telkens een bijna identiek plaatje is natuurlijk groot. Dan was epoch/random nog beter

Dit gaat vaak goed echter voor sommige plaatjes blijft hij herladen, vaag. I.i.g weer reden voor de mannen om een volgende release van FF en Chrome uit te brengen.

Als je nou eens zorgt dat je weet waar je over praat voor je met een schuldige vinger naar anderen wijst Die browsers heb dit toch wel basisbegrip al jaren goed onder de knie; IE was ooit in een grijs verleden nog een buitenbeentje wat dit betreft maar zelfs die snapt zoiets simpels inmiddels al een versie of 2, 3.
Je maakt jezelf belachelijk door de schuld bij de browsers neer te leggen terwijl je de basis zelf niet eens begrijpt.

Moet zeggen dat ik het op dit moment belangrijker vindt dat het werkt dan dat ik per keer zijn cache met 15kbyte per keer vervuil. Maar dat komt doordat ik een aantal zaken met hoge prioriteit heb. Volgens mij is er een maximum aan cache geheugen.

Had ik dat niet al aangekaart?

Eerlijk gezegd heb ik het idee dat ik wil, nog niet geïmplementeerd is in HTML, en dat waarschijnlijk pas in een later stadium gaat gebeuren

ik mag hopen van niet, en je kunt er gif op innemen dat dit ook niet gaat gebeuren. Dit soort zaken heeft helemaal niets, maar dan werkelijk ook helemaal niets, in de HTML standaard te zoeken. Ik verwees je niet voor niets naar de HTTP standaard.

en nu met allerlei foefjes op low-level niveau per browser kan manipuleren. Ik zie ontzettende complexe data specs voorbij komen van één of twee lagen lager in het OSI-model

OMG; iets met klok en klepel Welke laag anders dan de applicatielaag (HTTP) heb je voorbij zien komen dan? Je maakt me erg nieuwsgierig...

terwijl je natuurlijk iets wil als boven in je webpagina
set changepicture = smooth_transent
of als parameter meegeven in je stylesheet voor die betreffende div.

Euh ook zoiets gaat er niet komen maar je bent bekend met de mogelijkheden van CSS3 en/of JS?

Misschien hadden de programmeurs naar de leus van de belastingdienst moeten luisteren, mooier kunnen we het niet maken, makkelijker wel

Heb ik een leus voor jou: een betere wereld begint bij jezelf Zorg op z'n minst dat je een beetje weet waar je over praat voor je gaat klagen over zaken die, volgens jou, mis zijn. Want er is helemaal niets mis anders dan wat zaken die jij verkeerd doet en waarvan je de schuld op andere partijen afschuift

[gepebril]

@Roblll

Dank u wel voor je betoog. Zal er een paar dingen over zeggen.
Allereerst werk ik al meer dan 20 jaar in de ICT als systeemintegrator en ben afgestudeerd in Telematica. Dat wil niet zeggen dat ik alles weet, alleen weet wel alles van OSI, en de basis principes van computers en communicatie.
Filesize steeds het zelfde..... het gaat om snapshots van tv beelden... waarbij we pogen elke minuut een sample te nemen. Ken weinig TV zenders die 1 minuut lang het zelfde plaatje uitzenden. Lijkt me marketing technisch ook niet echt slim

Indien gelijksoortige acties niet consequent worden afgehandeld is er ergens iets niet in orde. Wellicht ben ik te vroeg met het vingertje geweest, echter er klopt ergens iets niet.

Alles is binnen techniek mogelijk en 'kan niet' bestaat simpelweg niet, daar heel basic gezegd communicatie een patroon van 0-en en 1-en is in een bepaalde volgorde. Kan een combinatie niet daar het conflict met een systemcall dan bestaat er een escape mogelijkheid waardoor het patroon toch verstuurd kan worden. 15 jaar geleden had ik een discussie bij Sun, toen nog een begrip in serverland, dat ik het absolute onzin vond dat het aanmaken van een paar partities 2xA4 aan code op de command line in beslag nam. Volgens hen kon het niet anders. Een jaar later bij een andere bijeenkomst was het commando plots daar.
De bottomline in techniek is dat nieuwe zaken worden ontwikkeld door mensen met hoge technische gaven die weinig zin en prioriteit geven aan optimalisatie, vereenvoudiging en leesbare documentatie. Dat was zo, dat is zo en dat zal altijd wel blijven. Daarom zag je heel vroeger computers bijna nergens en diende je, bijvoorbeeld je code voor elk type terminal aan te passen. Nu met HTML en paar regeltjes zet je een webomgeving op en ben je bereikbaar voor interactie met welk systeem dan ook. Wat je ziet is als de markt voor een type product groeit de eenvoud voor het bouwen van oplossingen toeneemt.
Wat mijn grote "issue" in dit verhaal is, is dat CSS tabellen updates vloeiend in elkaar overlopen echter dat de ontwikkelaars dat vergeten zijn mee te nemen voor plaatjes. Blijkbaar is er in PHP, HTML o.i.d nog geen algemene setting hoe jij de weergave van dynamische content eenvoudig weg kan afhandelen en automatisch aangemaakt wordt in je HTML template. Ik bedoel als ik bij Word elke 5 minuten een backup wil maken hoef ik echt geen cronjob/taskschedule aan te maken om "onderwater" de file automatisch te kopiëren en een andere naam te geven, dat is gewoon een optie met een vinkje in één van de pulldown menu's. Mocht MS dit om één of andere reden geweigerd hebben dit standaard in Word mee tenemen, dan wordt je als gebruiker gedwongen DOS/BASH te leren of 3rd party software te installeren. Zo kijk ik tegen het probleem aan.
Dus opmerkingen van dat gaat er niet komen, geloof ik niet. Wel dat als ik een telefoon koop dat de verkoper tegen mij zegt dat het de laatste is en dat de nieuwe bestelling pas over 2 weken afgeleverd wordt terwijl er in werkelijkheid nog 10 in het magazijn liggen.

Des al niet te min waardeer ik uw inzet op dit forum ontzettend en zal niet beweren dat u geen kennis van zaken hebt, het tegendeel is waar. Ik denk dat u alles weet van HTTP-headers en hoe ze toe te passen. We gaan wel een beetje Googlen op het Net naar HTTP-header background info, en leren begrijpen waarom ik daar kennis over dien te hebben om naast mijn CSS content ook mijn plaatjes de zelfde visuele presentatie te geven.

Dit lijkt me een mooi begin: http://net.tutsplus.com/t...http-headers-for-dummies/

Albert

Het is gewoon MS of Microsoft

[ Voor 1% gewijzigd door BtM909 op 13-02-2012 15:12 ]

[RobIII]

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Dank u wel voor je betoog. Zal er een paar dingen over zeggen.

Het is dat je zo'n epistel schrijft dat ik er op reageer; ik hoef mijn gelijk niet te hebben noch hoef ik iets te bewijzen, maar here goes...

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Allereerst werk ik al meer dan 20 jaar in de ICT als systeemintegrator en ben afgestudeerd in Telematica. Dat wil niet zeggen dat ik alles weet, alleen weet wel alles van OSI, en de basis principes van computers en communicatie.

Dan geef eens aan welke OSI lagen je allemaal voorbij had zien komen, waar ik op reageerde? Want anders dan de Applicatielaag heeft heel OSI niets in dit topic te zoeken. En met alle respect, als je "alles van OSI" weet had je die opmerking niet gemaakt want dan wist je dat 't slaat als een tang op een varken

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Filesize steeds het zelfde..... het gaat om snapshots van tv beelden... waarbij we pogen elke minuut een sample te nemen. Ken weinig TV zenders die 1 minuut lang het zelfde plaatje uitzenden. Lijkt me marketing technisch ook niet echt slim

Als je snapshots maakt die allemaal zullen schommelen rond de 15Kb dan is de kans op een indentieke filesize natuurlijk enorm; misschien niet binnen 20 plaatjes maar het gaat geheid gebeuren, daar kun je gif op innemen. Zoals ik zei: een time, random*9999999 oid zal vele malen beter werken dan filesize (los van 't feit dat dat, volgens mij althans, niet betrouwbaar cross-browser uit te lezen is).

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Indien gelijksoortige acties niet consequent worden afgehandeld is er ergens iets niet in orde. Wellicht ben ik te vroeg met het vingertje geweest, echter er klopt ergens iets niet.

Met alle respect, maar 't enige dat niet klopt is je redenering

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Alles is binnen techniek mogelijk en 'kan niet' bestaat simpelweg niet, daar heel basic gezegd communicatie een patroon van 0-en en 1-en is in een bepaalde volgorde. Kan een combinatie niet daar het conflict met een systemcall dan bestaat er een escape mogelijkheid waardoor het patroon toch verstuurd kan worden. 15 jaar geleden had ik een discussie bij Sun, toen nog een begrip in serverland, dat ik het absolute onzin vond dat het aanmaken van een paar partities 2xA4 aan code op de command line in beslag nam. Volgens hen kon het niet anders. Een jaar later bij een andere bijeenkomst was het commando plots daar.

Ik zeg niet dat 't niet kan maar dat 't niets in de HTML spec te zoeken heeft. Wat jij nu insinueert is vergelijkbaar met het proberen je remproblemen van je auto op te lossen door aan je achterlicht te rommelen. Het heeft niets met elkaar te maken en is niet nuttig. Caching-informatie heeft niets met HTML te maken. De browser heeft die informatie wel nodig om z'n werk te kunnen doen maar dat maakt niet dat die informatie daarom in HTML hoort; die informatie hoort in het transport: HTTP. En zo is het precies en zo zal 't ook blijven.

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Wat mijn grote "issue" in dit verhaal is, is dat CSS tabellen updates vloeiend in elkaar overlopen echter dat de ontwikkelaars dat vergeten zijn mee te nemen voor plaatjes.

Dat zijn ze helemaal niet; ook CSS heeft niets te maken met caching informatie. Het is gewoon simpele separation of concerns; dat is ook precies de reden waarom CSS naast HTML bestaat: CSS voor je opmaak, HTML voor je documentstructuur. En HTTP voor het transport. Het zijn allemaal "legoblokjes" die in elkaar passen en met elkaar samenwerken. We hebben een decennium terug hard gevochten om alle opmaak meuk uit HTML los te trekken naar CSS en jij stelt nu voor om al die zaken weer in elkaar te schuiven.

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Blijkbaar is er in PHP, HTML o.i.d nog geen algemene setting hoe jij de weergave van dynamische content eenvoudig weg kan afhandelen en automatisch aangemaakt wordt in je HTML template.

In PHP kun je prima inspelen op de HTTP headers; daar is header() voor uitgevonden. En daar is 't veel meer op z'n plek dan in de HTML spec.

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Mocht M$ dit om één of andere reden geweigerd hebben dit standaard in Word mee tenemen, dan wordt je als gebruiker gedwongen DOS/BASH te leren of 3rd party software te installeren. Zo kijk ik tegen het probleem aan.

Zolang je Microsoft, of MS, aangeeft als M$ vraag ik me af hoe serieus je eigenlijk bent of genomen wil worden...

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Dus opmerkingen van dat gaat er niet komen, geloof ik niet.

Knock yourself out, hoop tot je een ons weegt. Trust me, het komt er écht niet

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
Ik denk dat u alles weet van HTTP-headers en hoe ze toe te passen.

Ik weet niet alles (denk ik ), maar ik weet wel dat als ik worstel met een probleem en ergens op gewezen word ik me ga verdiepen in die materie en voor mezelf ga bepalen of ik iets heb aan die informatie en of ik er iets mee kan. Er wordt genoeg geblaat op internet, ook hier, en je zult altijd voor jezelf moeten nagaan hoe relevant bepaalde informatie voor je probleem is en voor jezelf moeten bepalen of je überhaupt op de juiste informatie bent gewezen. Uit je reacties maakte ik, tot op heden, echter niets anders op dan dat je geen puf hebt even een wikipedia documentje door te nemen (wat geen rocket science is) om daarna even "http headers caching" in google te mikkeren voor een crapload aan kant-en-klare oplossingen en tutorials en andere informatie over hoe je jouw probleem (goed) op kunt lossen.

gepebril schreef op zaterdag 11 februari 2012 @ 11:57:
We gaan wel een beetje Googlen op het Net naar HTTP-header background info, en leren begrijpen waarom ik daar kennis over dien te hebben om naast mijn CSS content ook mijn plaatjes de zelfde visuele presentatie te geven.

En nu zijn we aangekomen op 't punt waar ik reeds op aan stuurde; het was voor iedereen fijn geweest als dat een paar posts eerder was gebeurd

Ik wens je veel succes met 't doornemen en absorberen van alle informatie en wijs je graag even op 't feit dat je hier, nog steeds, van harte welkom bent met vragen. Ik hoop dat je volgende vraag, mocht je hier nog niet helemaal goed uit komen, in elk geval door laat schemeren dat je iets relevants hebt geprobeerd i.p.v. hebt lopen fantaseren over zaken die er nooit gaan komen en dat je dus wat beter beslagen ten ijs komt zodat we je snel op weg kunnen helpen met een concreet antwoord op een concrete vraag