Ankündigung

Einklappen
Keine Ankündigung bisher.

HTTP Caching Header

Einklappen

Neue Werbung 2019

Einklappen
X
Einklappen
  • Seite von 2
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige 1 2 Weiter
  • #1

    HTTP Caching Header

    Hi,

    bisher habe ich im Framework nur auf auf Expiration-HTTP-Header gesetzt und würde jetzt gern Validation hinzufügen. Ich bin mir allerdings etwas unsicher, ob ich das auch alles richtig verstanden habe, aber hab mir schonmal diesen Plan zurechtgelegt. Wäre das so umsetzbar? Muss ich auf irgendwelche Besonderheiten achten, wie z.B. abweichende Browser-Verhalten, Proxies, die Header killen usw.? Gibt es irgendwelche inhaltlichen Fehler in dieser Strategie?

    Hier der Plan:

    1. Skriptseitig ist kein Caching eingestellt:
    • ETag (md5 auf Content) verwenden, um "If-None-Match" zu triggern
    • Wenn ETag gleich, dann "304 Not Modified" senden
    • funktioniert das eigentlich auch, wenn "cache-control: no-cache" vorhanden ist?
    • Spart Bandbreite, aber keine CPU Power


    2. Skriptseitig ist schwaches Caching eingestellt (es wird nur das View gecacht, der Controller wird weiterhin ausgeführt):
    • ETag und Last-Modified verwenden, um "If-None-Match" und "If-Modified-Since" zu triggern
    • Spart Bandbreite und die CPU-Power zum Erstellen des Views


    3. Skriptseitig ist hartes Caching eingestellt (nicht mal der Controller wird ausgeführt)
    • Expires, Cache-Control, ETag und Last-Modified senden (hat Validation Vorrang vor Expiration? Wenn ja, müsste ich die Validation-Parameter erst nach Ablauf des Caches senden)
    • Nach Ablauf des Caches Umstellen auf schwaches Caching
    • Spart Bandbreite, CPU Power und vermeidet Netzwerk-Roundtrips


    Danke und Gruß,
    Christoph
    http://mcsodbrenner.blogspot.com/
    Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/
    Stichworte: -
  • #2
    Hallo Christoph,

    aus Erfahrung würde ich folgendes empfehlen: hartes HTTP-Caching mit versionierbaren URLs. Will heißen: wenn eine Resource seine Gültigkeit verliert, muss das über die URL erkennbar sein. Bei Bildern und CSS-/JS-Dateien ist das sehr einfach realisierbar, hier kannst du die Cache-Zeit auf 1 Jahr+ konfigurieren. Bei HTML-Dokumenten muss man etwas genauer hinsehen, es ist jedoch meistens eine Kombination aus Datum + ID + Version sinnvoll. Hierfür ist es empfehlenswert, Links automatisiert generieren zu lassen. Dann kannst du das Handling zentral ändern.

    Noch ein paar Worte zu deinen Punkten:
    • ETags sind nicht zu empfehlen, weil du dauernd revalidate-Anfragen bekommst.
    • Gleiches gilt für If-None-Match-Anfragen.
    • Für effektives Caching sollte Cache-Control, Date, Last-Modified und Expires gesetzt sein.
    • Sofern du auf Server-Seite CPU sparen möchtest, ist das View-Based-Caching-Konzept sinnvoll.

    Was deine Fragen zu der Priorität und Bedeutung der HTTP-Header angeht: RFC 2616
    Viele Grüße,
    Dr.E.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1. Think about software design [B]before[/B] you start to write code!
    2. Discuss and review it together with [B]experts[/B]!
    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
    4. Write [I][B]clean and reusable[/B][/I] software only!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Kommentar

    • #3
      dr.E:

      ETags sind nicht zu empfehlen, weil du dauernd revalidate-Anfragen bekommst.
      du machst doch beim view-based-caching nichts anderes, du generierst einen key, ueberpruefst ob es den content gibt und gibst ihn aus. beim ETag kommt dann nurnoch dazu, das du keine daten mehr uebertragen musst.
      oder sehe ich das falsch?
      [B]PHP4?!?[/B]>>>[B]Aktuelle[/B] PHP Version: [B]5.2.11 || 5.3.0
      [URL="http://en.opensuse.org/Factory/News"]Suse 11.2 *vorfreude*[/URL]
      [/B]

      Kommentar

      • #4
        oder sehe ich das falsch?
        Ja. Ein ETag muss mit einem HEAD-HTTP-Request validiert werden. Das ist dann (fast) ebenso schlimm wie eine komplette Anfrage. Du möchtest ja im Grunde vermeiden, dass der Client deine Infrastruktur kontaktiert. Das ist weder mit einem ETag noch mit einem If-None-Match möglich.
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar

        • #5
          Zitat von dr.e. Beitrag anzeigen
          Ja. Ein ETag muss mit einem HEAD-HTTP-Request validiert werden. Das ist dann (fast) ebenso schlimm wie eine komplette Anfrage. Du möchtest ja im Grunde vermeiden, dass der Client deine Infrastruktur kontaktiert. Das ist weder mit einem ETag noch mit einem If-None-Match möglich.
          ok, das ist jetzt klar.

          aus Erfahrung würde ich folgendes empfehlen: hartes HTTP-Caching mit versionierbaren URLs. Bei HTML-Dokumenten muss man etwas genauer hinsehen, es ist jedoch meistens eine Kombination aus Datum + ID + Version sinnvoll.
          wie loest du hier die problematik der externen verlinkung sowie der SuMa freundlichkeit (also kein doppelter content, dennoch soll die url zum - veraenderten - inhalt anders sein). leitest du da dann per HTTP 303 weiter?
          [B]PHP4?!?[/B]>>>[B]Aktuelle[/B] PHP Version: [B]5.2.11 || 5.3.0
          [URL="http://en.opensuse.org/Factory/News"]Suse 11.2 *vorfreude*[/URL]
          [/B]

          Kommentar

          • #6
            Ein ETag muss mit einem HEAD-HTTP-Request validiert werden. Das ist dann (fast) ebenso schlimm wie eine komplette Anfrage. Du möchtest ja im Grunde vermeiden, dass der Client deine Infrastruktur kontaktiert. Das ist weder mit einem ETag noch mit einem If-None-Match möglich.
            Ja, aber doch immerhin gut, wenn man kein eingestelltes Caching hat. Man spart zwar keine Ressourcen auf dem Server, aber dafür doch immerhin Traffic. Und das ohne Nachteile. Übersehe ich da etwas?

            Für effektives Caching sollte Cache-Control, Date, Last-Modified und Expires gesetzt sein.
            Last-modified ist doch ein Expiration-Parameter? Ist Date tatsächlich ein Caching-relevanter Parameter?

            Was deine Fragen zu der Priorität und Bedeutung der HTTP-Header angeht: RFC 2616
            Das hatte ich mir auch schon vorgenommen, aber dazu irgendwie nichts gefunden Welche Stelle meinst du?
            http://mcsodbrenner.blogspot.com/
            Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

            Kommentar

            • #7
              Ja, aber doch immerhin gut, wenn man kein eingestelltes Caching hat. Man spart zwar keine Ressourcen auf dem Server, aber dafür doch immerhin Traffic. Und das ohne Nachteile. Übersehe ich da etwas?
              Nein, weil die meisten Standard-Applikationen keinen HEAD-Request unterstützen. Oder tust du das etwa?

              Last-modified ist doch ein Expiration-Parameter? Ist Date tatsächlich ein Caching-relevanter Parameter?
              Nein, aber es unterstützt den Browser bei der Entscheidung, ob ein Inhalt im Cache noch valide ist oder nicht. Date hilft im Zusammenspiel mit Last-Modified und dem max-age-Modifier bei fehlendem Expires das Ende der Gültigkeit eines Objekts zu berechnen.

              Welche Stelle meinst du?
              Die Sektionen der genannten Header...
              Viele Grüße,
              Dr.E.

              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              1. Think about software design [B]before[/B] you start to write code!
              2. Discuss and review it together with [B]experts[/B]!
              3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
              4. Write [I][B]clean and reusable[/B][/I] software only!
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              Kommentar

              • #8
                Zitat von dr.e. Beitrag anzeigen
                Nein, weil die meisten Standard-Applikationen keinen HEAD-Request unterstützen. Oder tust du das etwa?
                "If-Modified-Since" wird vom Client nicht per HEAD-Request geschickt, weil er ja sonst im Falle eines Hits noch einen Request schicken müsste, um den neuen Inhalt abzufordern. Stattdessen sendet er einen GET-Request, den man entweder mit einer ganz normalen Seite oder mit einem "403 Not modified" und leerem Body beantwortet.
                So verstehe ich zumindest:
                HTTP/1.1: Header Field Definitions (mit Anchor zur richtigen Stelle )

                Zitat von dr.e. Beitrag anzeigen
                Date hilft im Zusammenspiel mit Last-Modified und dem max-age-Modifier bei fehlendem Expires das Ende der Gültigkeit eines Objekts zu berechnen.
                Die RFC stellt da keinen Zusammenhang her. Wäre doch auch überflüssig, da der Client in dem Falle seine eigene Zeit nehmen kann.

                Zitat von dr.e. Beitrag anzeigen
                Die Sektionen der genannten Header...
                Hab ich durchgelesen... ich finds nicht...
                http://mcsodbrenner.blogspot.com/
                Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

                Kommentar

                • #9
                  Hi,

                  soweit ich
                  See section 13.3.3 for rules on how to determine if two entities tags match. The weak comparison function can only be used with GET or HEAD requests.
                  interpretiere, sollte das mit beiden funktionieren...

                  Wäre doch auch überflüssig, da der Client in dem Falle seine eigene Zeit nehmen kann.
                  Nicht ganz. Hier ist vor allem die Zeitzone des Servers interessant, die nicht immer gleich der des Clients ist.

                  Hab ich durchgelesen... ich finds nicht...
                  Du warst schon an den richtigen Stellen, nur meine Erfahrungen - nachdenen du vermutlich suchst - stehen da nicht drin.
                  Viele Grüße,
                  Dr.E.

                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  1. Think about software design [B]before[/B] you start to write code!
                  2. Discuss and review it together with [B]experts[/B]!
                  3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                  4. Write [I][B]clean and reusable[/B][/I] software only!
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                  Kommentar

                  • #10
                    Datumsangaben sollten imho bei http-kram IMMER GMT sein

                    RFC 2616 (rfc2616) - Hypertext Transfer Protocol -- HTTP/1.1
                    All HTTP date/time stamps MUST be represented in Greenwich Mean Time
                    (GMT), without exception. For the purposes of HTTP, GMT is exactly
                    equal to UTC (Coordinated Universal Time). This is indicated in the
                    first two formats by the inclusion of "GMT" as the three-letter
                    abbreviation for time zone, and MUST be assumed when reading the
                    asctime format. HTTP-date is case sensitive and MUST NOT include
                    additional LWS beyond that specifically included as SP in the
                    grammar.
                    [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
                    | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

                    Kommentar

                    • #11
                      Zuletzt geändert von McSodbrenner; 21.08.2009, 16:06.
                      Habs gerade eingebaut und funktioniert 1a!

                      Zitat von dr.e. Beitrag anzeigen
                      soweit ich interpretiere, sollte das mit beiden funktionieren...
                      Jupp, macht halt nur bei HEAD wenig Sinn

                      Zitat von dr.e. Beitrag anzeigen
                      Nicht ganz. Hier ist vor allem die Zeitzone des Servers interessant, die nicht immer gleich der des Clients ist.
                      Jupp, da bin ich bei Robo. Also sollte Date kein Problem sein. Aber ich werd das gleich mal testen mit falschen Date-Angaben.

                      Zitat von dr.e. Beitrag anzeigen
                      Du warst schon an den richtigen Stellen, nur meine Erfahrungen - nachdenen du vermutlich suchst - stehen da nicht drin.
                      Die Killerantwort

                      @dr.e: Wie hast du das eigentlich mit SEO, Duplicate Content und deinen URLs gelöst?

                      Viele Grüße!
                      http://mcsodbrenner.blogspot.com/
                      Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

                      Kommentar

                      • #12
                        Zitat von robo47
                        Datumsangaben sollten imho bei http-kram IMMER GMT sein
                        Korrekt, und zwar nach RFC 822.Ich habe jedoch beim letzten Optimierungs-Projekt gesehen, dass falsche Datums-Angaben ältere Browser (ich will ja keinen Namen nennen ) dazu verleitet haben, die Resource nicht zu cachen. Das hat im Speziefischen vermutlich weniger mit dem Date- als mit dem Last-Modified-Header zu tun. Es schadet jedoch nicht diesen Header in der Applikation zu setzen. Üblicherweise setzen diesen die HTTP/1.1-kompatiblen Server ohnehin selbst in den Response.

                        Die Killerantwort
                        Naja, das sind empirisch gewonnen Fakten. Was soll ich da mehr zu sagen.

                        @dr.e: Wie hast du das eigentlich mit SEO, Duplicate Content und deinen URLs gelöst?
                        Ich persönlich arbeite mit eindeutigen und sprechenden URLs und einer definierten Cache-Zeit.

                        Ein typischer Image-Response auf die versionierte URL http://www.domain.tld/images/version...6/my-image.gif würde bei mir so aussehen:

                        Code:
                        Date         : Fri, 21 Aug 2009 16:06:47 GMT
Last-Modified: Mon, 10 Aug 2009 17:54:28 GMT
Cache-Control: public; max-age=31536000
Expires         : Sat, 21 Aug 2010 18:06:47 GMT
Content-Type : image/gif
                        Bei Anfragen der Webseite http://www.domain.tld/Services/Mail-...ee-Mail-Server sieht der Header wie folgt aus:

                        Code:
                        Date         : Fri, 21 Aug 2009 16:06:47 GMT
Last-Modified: Mon, 10 Aug 2009 17:54:28 GMT
Cache-Control: public; max-age=172800
Expires         : Sat, 23 Aug 2010 16:06:47 GMT
Content-Type : text/html; charset=utf8
                        Sofern ein Dokument über einen längeren Zeitraum gecached werden soll, wird dieses mit einem eindeutigen Identifier ausgestattet: http://www.domain.tld/2009-08-21/Services/Mail-Services/Free-Mail-Server. Auf Server-Seite zerlege ich diese URL dann mit Hilfe eines Input-Filters, fülle das Model der Anwendung und entscheide an Hand des Datums, ob diese Ressource in einer neueren Version vorliegt. Zur Unterscheidung muss man nicht unbedingt ein Datum verwendenes tut auch eine eindeutige Versionsnummer der Webseite. Sollte Content in einer veralteten Version geliefert werden, wird der Benutzer mit einem permanent redirect auf die neue umgeleitet. So kann die Suchmaschine ihren Index vernünftig pflegen. Noch Fragen?
                        Viele Grüße,
                        Dr.E.

                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        1. Think about software design [B]before[/B] you start to write code!
                        2. Discuss and review it together with [B]experts[/B]!
                        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                        4. Write [I][B]clean and reusable[/B][/I] software only!
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                        Kommentar

                        • #13
                          Man ist ja als Webentwickler nicht gerade dazu verpflichtet, seine komplette Website zu versionieren.

                          Mich würde interessieren, warum du diesen Weg gewählt hast und nicht immer dieselbe URL gewählt hast und die zur Verfügung stehenden HTTP-Parameter genommen hast? Welchen Vorteil hat deine Variante?

                          Grüzi,
                          Christoph
                          http://mcsodbrenner.blogspot.com/
                          Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

                          Kommentar

                          • #14
                            Hi,

                            Man ist ja als Webentwickler nicht gerade dazu verpflichtet, seine komplette Website zu versionieren.
                            Ein gutes CMS erledigt das für dich völlig transparent, da solltest du dich nicht drum kümmern müssen. Sofern du nicht versionieren möchtest, musst du das auch nicht tun, es gibt ja auch andere Möglichkeiten.

                            Mich würde interessieren, warum du diesen Weg gewählt hast und nicht immer dieselbe URL gewählt hast und die zur Verfügung stehenden HTTP-Parameter genommen hast? Welchen Vorteil hat deine Variante?
                            Bei Bildern ist die URL ohnehin quasi egal, hier geht es nur darum, dass die URL für cachebare Inhalte konstant ist. Bei Webseiten hingegen ist es aus SEO-Gründen wichtig, die Schlüsselwörter in der URL zu platzieren. Eines der relevanten Keywords ist das Datum, an dem die Aktualität der Resource erkennbar ist. Dieses Format siehst du auch häufig bei Blogs.
                            Der genannte Weg ist jedoch nicht etweder URL oder Header, sondern eine sinnvolle Kombination beider Elemente. Eine URL, die Versions-Informationen enthält, kannst du länger cachen, als eine URL ohne diese.
                            Viele Grüße,
                            Dr.E.

                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                            1. Think about software design [B]before[/B] you start to write code!
                            2. Discuss and review it together with [B]experts[/B]!
                            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                            4. Write [I][B]clean and reusable[/B][/I] software only!
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            Kommentar

                            • #15
                              Zitat von dr.e. Beitrag anzeigen
                              Bei Webseiten hingegen ist es aus SEO-Gründen wichtig, die Schlüsselwörter in der URL zu platzieren. Eines der relevanten Keywords ist das Datum, an dem die Aktualität der Resource erkennbar ist. Dieses Format siehst du auch häufig bei Blogs.
                              Stimmt schon, bei Blogs (Artikel-basierten Seiten) ist das Datum in der Tat ein hilfreiche Sache, um die Aktualität beurteilen zu können. Allerdings doch nur für den Besucher. Dass die Suchmaschine das Datum auswertet ist doch recht unwahrscheinlich.
                              Auch Matt Cutts, immerhin Google-Mitarbeiter, hat vor einiger Zeit dazu geraten, das Datum aus der URL zu verbannen.

                              Und durch die URL-Tiefe macht man seine Seiten ja unwichtiger, da die eigentlich Keywords in der Hierarchie weit hinten/unten stehen. Müsste das nicht eigentlich gegen so ein Format sprechen?
                              http://mcsodbrenner.blogspot.com/
                              Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

                              Kommentar

                              Vorherige 1 2 Weiter
                              Lädt...
                              X