Last-Modified und bei if_modified_since CGI beenden? (gelöst) (Perl/CGI)

[thread]16127[/thread]

Last-Modified und bei if_modified_since CGI beenden? [gelöst]

Leser: 21

Articles: hide open all | hide show old branches

+25 replies
rosti

2011-03-30 15:14

User since
2011-03-19
3194 Artikel
BenutzerIn

Hi,

z.Z. schicke ich im CGI nur den Response-Header
Last-Modified: ...

und überlasse es dem Webserver, was er damit macht; die Webserver, die hier so rumstehen, machen das was ich erwarte: sie senden einen "Status: 304 Not Modified"; womit der UA die Seite aus dem Cache holt, das CGI jedoch weiter läuft und Content in Richtung Webserver schickt, Content, der eigentlich nicht mehr gebraucht wird.

Die Frage ist, ob es Sinn macht, den Request-Header IF_MODIFIED_SINCE auszuwerten, bereits im CGI die Übereinstimmung zu prüfen und ggf. das CGI vorzeitig zu beenden?

Edit: Es geht nur um eine Abkürzung von (wahrscheinlich) wenigen Millisekunden und um ein paar weniger Bytes, die der Webserver kriegt.

Rolf
Last edited: 2011-03-30 15:17:16 +0200 (CEST)
- +16 replies
- GwenDragon
  
  2011-03-30 15:16
  
  User since
  2005-01-17
  14533 Artikel
  Admin1
  
  Bei statischen Inhalten wie Bildern oider "normalen" HTML macht das ja der Server selbst anhand der mtime der Datei.
  
  Aber bei dynamischen Inhalten sollte das CGI den IF_MODIFIED_SINCE auswerten und bei Bedarf nur 304 ohne Content senden.
  
  //EDIT: Zudem schont es bei Leuten mit wenig Bandbreite oder ohne Flatrate den Geldbeutel und Nerven.
  Last edited: 2011-03-30 15:18:23 +0200 (CEST)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +15 replies
  - rosti
    
    2011-03-30 15:51
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Ja, das ist klar. Ich habe hier ein, nennen wir es Template-System am Wickel, ein CGI-Script für "alles", je nach Template wird in die Response ein Last-Modifed gesteckt oder auch nicht. Das hängt davon ab, ob sich die Inhalte kurz- oder langfristig ändern und ist in meiner Anwendung recht einfach konfigurierbar.
    
    Den If-modified-since Header sendet der Browser, sofern er das kann oder darf und der kommt zuerst am Webserver an, erst dann über die CGI-Schnittstelle am Script.
    
    Sofern der Webserver bei einem If-modified-since von selbst einen 304-Status schickt, isses dem egal, was da noch vom CGI-Script kommt und ob im Script dieser Header überhaupt Beachtung findet.
    
    Hier setzt meine Frage an: Lohnt es sich überhaupt, If-modified-since im CGI-Script auszuwerten um es ein paar Millisekungen früher zu beenden?
    - +14 replies
    - GwenDragon
      
      2011-03-30 16:00
      
      User since
      2005-01-17
      14533 Artikel
      Admin1
      
      Deine Webanwenungen antworten im Millisekundenbreeich? Wow. Nee, nicht wirklich oder?
      
      Wenn die Webanwendung viel zu verarbeiten hat, kann doch die Antwortzeit und danach die Auslieferung des Contents an den Browser dauern.
      Du musst das immer eher von der Clientseite sehen, es sei den der Server istz schwach.
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +13 replies
      - rosti
        
        2011-03-30 17:12
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2011-03-30T14:00:28 GwenDragon
        Deine Webanwenungen antworten im Millisekundenbreeich? Wow. Nee, nicht wirklich oder?
        
        Aber nicht doch neeeein ;)
        
        Es gibt, erst _nachdem ein CGI gestartet ist_ einen Unterschied, ob 10 KB oder 100 KB zum Webserver geschickt werden, nur um diesen Unterschied geht es und der dürfte im ms-Bereich, auf jeden Fall sehr deutlich unter einer Sekunde, liegen.
        
        Quote
        Wenn die Webanwendung viel zu verarbeiten hat, kann doch die Antwortzeit und danach die Auslieferung des Contents an den Browser dauern.
        
        Zwischen Webanwendung und Browser liegt immer noch der Webserver. Wenn der Webserver den Request mit Status 304 beantwortet, wird das CGI wahrscheinlich gar nicht erst gestartet, ist das so?
        
        +6 replies
        
        pq
        
        2011-03-30 18:26
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        cgi-scripte wird der webserver bestimmt nicht eigenmächtig mit 304 beantworten =)
        dafür muss dein script erst gestartet werden und header liefern.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        GwenDragon
        
        2011-03-30 18:39
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Korrekt! ;)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +4 replies
        
        rosti
        
        2011-03-30 18:40
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2011-03-30T16:26:56 pq
        cgi-scripte wird der webserver bestimmt nicht eigenmächtig mit 304 beantworten =)
        
        Status: 304 Not Modified
        
        kommt definitiv vom Webserver und nicht von meinem Script. Das kann ich mit absoluter Sicherheit feststellen ;)
        
        Wo ich mir nicht ganz sicher bin: Ob das CGI überhaupt gestartet wird, wenn der Server einen 304 sendet und danach ein Connection: Close.
        
        Rolf
        
        bianca
        
        2011-03-30 18:55
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        2011-03-30T16:40:06 rosti
        Status: 304 Not Modified
        kommt definitiv vom Webserver und nicht von meinem Script.
        
        Ich glaube, das war auch nicht gemeint. Gemeint war wahrscheinlich, dass der Webserver dein Script erst starten muss um zu entscheiden, ob sich die Daten seit dem letzten Abruf geändert haben. Und das macht er m.E. aufgrund der Header die dein Script liefert oder eben halt nicht liefert.
        So zumindest habe ich die Funktion von 304 verstanden.
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        GwenDragon
        
        2011-03-30 19:07
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Gerade lokal mit HEAD getestet.
        Das 304 wwird nur bei statischen Seiten/Dateien durch den Server gesendet!
        Bei einem CGI wird kein Last-Modified-Header druch den Server eingefügt.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        rosti
        
        2011-03-30 19:40
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2011-03-30T17:07:45 GwenDragon
        Gerade lokal mit HEAD getestet.
        Das 304 wwird nur bei statischen Seiten/Dateien durch den Server gesendet!
        Bei einem CGI wird kein Last-Modified-Header druch den Server eingefügt.
        
        Logo, wäre ja noch schöner :P
        
        Nichts spricht jedoch dagegen, dass das CGI ggf. einen Last-Modified sendet. Insbesondere dann, wenn mod_rewrite _alle_ Request-Uri's auf ein einziges CGI-Script umschießt (Ausnahmen in RewriteCond), ist das immer eine Überlegung wert; wenn also Inhalte dabei sind, die sich nur langfristig ändern. Lastmod wird natürlich nicht gesendet, wenn das Script Formulare verarbeitet oder dynamischen Content (z.B. einen Warenkorb) ausgibt.
        
        +6 replies
        
        GwenDragon
        
        2011-03-30 18:45
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Ähm, erst geht der Request an den Webserver.
        Der startet das CGI mit der Webanwendung.
        Das wurschtelt meist bedeutend länger um als nur 5 oder 10 ms, selbst mit mod_perl.
        Dann sendet es den Content an den Browser.
        Das dauert.
        
        Selbst Zehntel- oder Hundertstel Sekunden schlagen sich nieder auf Besucherzahlen, das war auch bspw. bei kommerziellen Shops oder Websites gut im derzeitigen Ausgabe 9 (Print) des Webstandards-Magazin zu lesen.
        
        Das meine ich.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +5 replies
        
        rosti
        
        2011-03-30 19:04
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2011-03-30T16:45:26 GwenDragon
        Ähm, erst geht der Request an den Webserver.
        Der startet das CGI mit der Webanwendung.
        
        Ok, weiter gehts dann so
        - Das CGI sendet einen Last-Modified Header und den Content
        - Der Webserver reicht das durch zum Browser
        
        Jetzt der nächste Request auf dieselbe Ressource:
        - Browser sendet Request mit dem Header If-modified-since
        Arrggh, also doch:
        - Der Webserver startet das CGI
        - und das CGI sendet den
        Last-Modified Header
        
        Also wird das CGI gestartet ;)
        
        Was jetzt passiert kann ich mir nur so erklären:
        Der Webserver vergleicht If-modified-since mit last-modified und sendet einen Status 304 sowie connection: close.
        
        Das CGI läuft unnütz weiter! Also Frage nr. 1: Lohnt es sich, das abzukürzen? Bei vielen Besuchern ja, denke ich....
        
        +4 replies
        
        GwenDragon
        
        2011-03-30 19:09
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Ja, solltest du. Wer will denn jedesmal ein paar Hundert Kilo neu empfangen wenn sich nix geändert hat.
        Das erfreut auch Proxies.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +3 replies
        
        rosti
        
        2011-03-30 19:27
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Ok, mache ich. Aber erst nach dem Essen ;)
        
        Viele Grüße an Alle,
        Rolf
        
        @bianca: ja, das CGI wird in jedem Fall gestartet, den Vergleich jedoch macht der Webserver (status 304).
        
        Das CGI kann ich verbessern, indem es auch vergleicht und füher beendet werden kann. Alles klar.
        
        +2 replies
        
        bianca
        
        2011-03-30 20:08
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        2011-03-30T17:27:05 rosti
        @bianca: ja, das CGI wird in jedem Fall gestartet, den Vergleich jedoch macht der Webserver (status 304).
        
        Ja, genau das hab ich geschrieben. Oder nicht? ;)
        10 print "Hallo"
        20 goto 10
        
        rosti
        
        2011-03-30 20:38
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Korrekt, jetzt sind wir alle gut beisammen ;)
        
        Schönen Abend, euch allen.
        Rolf
- +8 replies
- pq
  
  2011-03-30 15:16
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  ja, macht unter umständen sinn. kommt drauf an, wieviel arbeit und traffic es erspart.
  ich mache das hier im forum zum beispiel beim rss-feed.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +7 replies
  - kristian
    
    2011-03-30 22:09
    
    User since
    2005-04-14
    684 Artikel
    BenutzerIn
    
    hmmm, das erstaunt mich etwas.
    Mal abgesehen vom gesteuerten 304, haben hier nicht alle Seiten ein last_modified basierend auf der letzten Ändererung der DB, bezüglich der jeweiligen Seite?
    
    EDIT:
    Das würde bedeuten du setzt LAST_MODIFIED richtig, ignorierst aber normalerweise ein IF_MODIFIED_SINCE?
    Last edited: 2011-03-30 22:12:33 +0200 (CEST)
    - +6 replies
    - pq
      
      2011-03-30 22:20
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      2011-03-30T20:09:03 kristian
      EDIT:
      Das würde bedeuten du setzt LAST_MODIFIED richtig, ignorierst aber normalerweise ein IF_MODIFIED_SINCE?
      
      genau. bei solch dynamischen seiten ist das irgendwie sinnlos. aber den last-modified-header setze ich trotzdem, soweit ich das sehe, wird er auch von suchmschinen ausgewertet und erscheint ab und zu in den suchergebnissen.
      
      edit: sehe gerade, dass google da aber auch ab und zu mist baut. wenn ich nach dem titel dieses threads suche, erscheint bei den meisten ergebnissen richtigerweise der 30. märz, bei manchen aber auch der 19. märz...
      Last edited: 2011-03-30 22:25:19 +0200 (CEST)
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +5 replies
      - kristian
        
        2011-03-30 22:55
        
        User since
        2005-04-14
        684 Artikel
        BenutzerIn
        
        Jein, es ist in der Praxis etwas anders.
        z.B.:
        Mein Bot fragt bislang nur LAST_MODIFIED ab und nimmt das mit.
        
        Später im NEXST-STEP wäre es denkbar, dass er den Index befragt und einen IF_MODIFIED_SINCE sendet.
        
        Da wäre es sinnig, wenn du die Anfrage entsprechend des LAST_MODIFIED richtig, sprich ggf. mit 304 beantworten würdest.
        
        OK, das war mein Ding und meine Vision.
        
        Zurück zur Realität.
        Wenn die Tante G. mit irgendwas ein Problem hat, dann ist es der Traffic.
        Wer mir nicht glauben will der schaue sich Page-Speed an.
        
        Es schaut so aus als wäre die Tante bei korrekter Antwort auf IF_MODIFIED_SINCE auch nicht traurig.
        
        Naja, die Tante oder mein Traum und ich, Sinn macht es auf jeden Fall, wenn der Aufwand nicht zu hoch ist.
        
        +4 replies
        
        pq
        
        2011-03-30 23:11
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        es ist nur etwas problematisch auf einer seite, auf der man sich einloggen kann. stell dir vor, du bist eingelogt, rufst ein paar threads auf, logst dich aus und rufst dann nochmal eine der seiten von vorher auf. dann würdest du auf dieser seite dich noch als eingelogt sehen. andererseits setze ich ja den no-cache header.
        
        als alternative könnte ich bei allen aufrufen von eingelogten usern gar keinen last-modified-header setzen.
        
        in jedem fall muss ich schauen, dass ich das korrekt mache.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +3 replies
        
        kristian
        
        2011-03-30 23:27
        
        User since
        2005-04-14
        684 Artikel
        BenutzerIn
        
        ich sehe dein primäres problem; indes es ist nicht wirklich.
        Wenn du ein LAST_MODIFIED hinbekommst und so sieht es aus, kannst du auch mit IF_MODIFIED_SINCE umgehen.
        Eingelogte User bzw. deren Browser arbeiten ja auch nur mit der Technik.
        Es sollte egal sein ob ich eingelogt bin oder nicht, das Änderungsdatum einer Seite bleibt, die Info, was ich gesehen habe oder nicht (dementsprechend auf oder zu) ist ja wohl im Cookie bzw. in der Session zum Keks.
        
        EDIT:
        Ich räume ein, dass ich keine Ahnung habe ob ein Cookie bei einem 304 genommen wird.
        Es kann wohl eher nicht sein, von daher, hmmm Tina ist wohl richtig unterwegs....
        Last edited: 2011-03-30 23:34:36 +0200 (CEST)
        
        +2 replies
        
        rosti
        
        2011-03-31 09:04
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Moin;
        
        es ist richtig, derzeit werte ich IF_MODIFIED_SINCE im Script nicht aus, sondern setze nur den LAST_MODIFIED in die Response. Das ist mir möglich, weil im CMS auch die "mtime" hinterlegt ist und {lastmod} eines der Attribute für die auszugebende Ressource ist.
        
        Möglich wäre auch, einen ETag zu generieren, tatsächlich empfehlen Suchmaschinenbetreiber jedoch, Lastmod zu verwenden.
        
        Sofern der Webserver entsprechend konfiguriert ist, vergleicht er IF_MODIFIED_SINCE (Request) mt LAST_MODIFIED was er vom CGI bekommt, sendet bei Übereinstimmung einen 304 und schließt die Verbindung. Da hatte ich gestern einen Denkfehler, es ist klar, dass der Webserver das CGI startet, ansonsten hätte er keinen Vergleich (danke Bianca).
        
        Mit Cookies hat das alles nichts zu tun, aber es macht keinen Sinn, etwa einen Hinweis "Bitte Cookie annehmen" in eine Seite einzubauen, die mit einem LastMod ausgeliefert wird, denn die nimmt der Browser in den Cache und cacht auch den Hinweis, obwohl der Browser den Cookie angenommen hat.
        
        Fazit: Den Request-Header IF_MODIFIED_SINCE im CGI auswerten zu müssen, hängt von der Konfiguration des Webservers ab, also ob der Server die Zeiten vergleicht und sich um den 304 kümmert, oder das im CGI programmiert werden muss. Allein aufgrund dieser Abhängigkeit ist es gut, den IF_MODIFIED_SINCE auch im CGI auszuwerten, im CGI einen 304 zu senden und die weitere Auslieferung von Content zu stoppen.
        
        Quote
        ..ob ein Cookie bei einem 304 genommen wird.
        
        Die Frage habe ich so noch nicht gestellt. Da wäre zunächst zu klären, ob der Webserver zuerst den Cookie sendet und danach den 304 oder umgekehrt. Im ersten Fall vermute ich, dass der Browser den Cookie annimmt, im Zweiten nicht. AAAberrrrrr:
        
        Edit: Quatsch, der Status kommt _immer_ zuerst :)
        
        Sofern diese Frage wirklich akut werden sollte, würde ich das mal testen und unbedingt in die RFCs schauen, was dazu steht. Wenn es nicht gerade ein Non-parsed-Header-Script ist, was das CGI sendet, bestimmt der Webserver die Reihenfolge der Response-Header.
        
        Bis dann ;)
        Rolf
        
        Edit: Test, Annahme Cookie bei 304, gesendet wird er und FF speichert ihn.
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
        
        http://test/ GET / HTTP/1.1 Host: test User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive If-Modified-Since: Tue, 29 Mar 2011 18:34:48 GMT Cache-Control: max-age=0 HTTP/1.1 304 Not Modified Date: Thu, 31 Mar 2011 07:06:46 GMT Server: Apache/2.2.14 (Win32) PHP/5.3.0 Connection: Keep-Alive Keep-Alive: timeout=5, max=100 Set-Cookie: PICOSHOP=09a39c33fcd459e07503b88d82507509; path=/ ---------------------------------------------------------- http://test/nv.css GET /nv.css HTTP/1.1 Host: test User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Accept: text/css,*/*;q=0.1 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: PICOSHOP=09a39c33fcd459e07503b88d82507509 If-Modified-Since: Wed, 30 Mar 2011 10:51:37 GMT Cache-Control: max-age=0 HTTP/1.1 304 Not Modified Date: Thu, 31 Mar 2011 07:06:47 GMT Server: Apache/2.2.14 (Win32) PHP/5.3.0 Connection: Keep-Alive Keep-Alive: timeout=5, max=99 ----------------------------------------------------------
        
        Last edited: 2011-03-31 09:14:10 +0200 (CEST)
        
        rosti
        
        2011-04-04 20:35
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Eine kleine Zusammenfassung gebe ich gerne noch hinzu ;)
        
        Sofern das CGI Last-Modified der Ressource serverseitig kennt, gibt es zwei Möglichkeiten:
        
        1. das CGI sendet einfach den Last-Modified Header und der Webserver kümmert sich um den Status 304, sofern ein Solcher vorliegt. Nachteil: Das CGI läuft unnütz weiter. Vorteil: wenig Tipparbeit
        
        2. das CGI kümmert sich selbst um IF_MODIFIED_SINCE und den Status 304. Sofern ein Status 304 vorliegt, sendet das CGI diesen Status an den Webserver und wird beendet. Nachteil: Ein bischen mehr Tipparbeit aber verlässlicher (Vorteil).
        
        Ein bischen Code:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
        
        sub mod304{ my $self = shift; my $lastmod = time2str($self->{lastmod}); if( exists($ENV{HTTP_IF_MODIFIED_SINCE}) && ($lastmod eq $ENV{HTTP_IF_MODIFIED_SINCE}) ){ return 'Status: 304 Not Modified'; } else{ return; } } # HTTP::Date::time2str, str2time # in Richtung Webserver: # print "Status: 304 Not Modified\n\n"; # Leerzeile! # exit 0;
        
        In meinem customCGI.pm, was von CGI.pm die Methoden erbt, verwende ich dazu eine eigene header-Methode, die CGI::header komplett überschreibt.
        
        --Rolf
        
        Last edited: 2011-04-04 20:36:40 +0200 (CEST)

View all threads created 2011-03-30 15:14.