Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

Re(3): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

Glockman — Tue, 01 May 2007 22:29:56 GMT

Danke für das Update

Klar, sowas interessiert mich immer - insbesondere dann, wenn ich wie hier komplett daneben gelegen bin
Ich les' mir das morgen in aller Ruhe mal durch und gelobe erst wieder mitzureden, wenn ich mich mit der Materie besser auskenne (sonst kommt wieder nur Stuss dabei raus ).

Gute Nacht,

Re(2): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Tue, 01 May 2007 22:18:51 GMT

Falls es dich noch interessiert:
ETags findest hier erklärt:
http://www.html-world.de/program/http_7.php
http://caching.ulf-wendel.de/http/caching_support_beispiel4.php
http://xhtmlforum.de/35221-php-session-etag-header.html

Insbesondere xhtmlforum fand ich gut.

Wenn ich es richtig habe:
- Bekommt jedes Dokument ein eindeutiges ETag (EntityTag).
- Vary definiert, daß es zu dem Dokument mehrere Sourcen geben kann (gzip, original, Sprachbezogen, ...) - und daß der Client sich entscheiden soll.

Ein ETag ist also ein Super-Mittel um Dokumente eindeutig zu erkennen.
Der Apache baut jetzt den Hund, daß sowohl ein ungezipptes als auch ein gezipptes Dokument denselben ETag erhalten.

Wenn man diese Option aufdreht, baut Squid einen Workaround:
Er betrachtet Dokumente mit gleichem ETag als unterschiedlich, wenn unterschiedliche vary-Replies kamen.

Vorteil: Sauberes Caching
Nachteil: Mehr Speicherbedarf (weil dasselbe Dokument nun mehrfach gecacht werden kann (1x pro vary), mehr NW-Bedarf (weil dasselbe Dok nun 2x geholt werden kann) und wohl mehr CPU-Leistung (weil match auf "Server APACHE").

So meine Vermutung nun ...

Re(2): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Tue, 01 May 2007 22:18:51 GMT

Re(2): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Tue, 01 May 2007 22:18:51 GMT

Re(5): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

Glockman — Tue, 01 May 2007 17:40:06 GMT

Deine These dazu ?

Meine These: ich hab mich schon zu weit aus dem Fenster gelehnt ohne mich auszukennen, ich sag' nichts mehr ohne Anwalt

Aber ich hab mir kurz durchgelesen, wovon ich nix versteh (GET und POST unter http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html ), und da steht unter anderem:
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.
Und bei POST: Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
Also irgendwie (fast) das Gegenteil von dem, was wir da gerade zu erörtern versuchen.

Was das jetzt für die mit "?"-parametrisierten Aufrufe genau heißt entzieht sich aber leider meiner Kenntnis. Dafür verstehe ich eindeutig zu wenig davon.

Ich seh' schon, ich bin keine große Hilfe

Re(4): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Tue, 01 May 2007 15:55:00 GMT

Es klang nur eben aufgrund meiner Beobachtungen sehr vernünftig.

Vielleicht nicht sehr hilfreich, aber eben meine Interpretation des Ganzen.

Das glaube ich Dir eh...

Mir bleibt nur unklar, wieso GET-Requests (Also Formulare mit Parametern via "?") ein Problem darstellen können - und man drum das cachen hier deaktivieren soll - aber ein cachen von POST-Requests (also ohne "?") kein Problem darstellt...

Deine These dazu ?

Re(3): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

Glockman — Tue, 01 May 2007 09:33:21 GMT

... das klang für mich überhaupt nicht nach Encoding im Sinne von
Zeichensätzen - insbesondere wegen on-the-fly Content-Encoding, returning the
same ETag on both plain and gzip:ed variants.. [...] Sicher, daß Du da recht hast ?

Äh - ja, ich meinte auch kein Text enconding - GZip sagt mir was, auch wenn ich meinen Schwerpunkt ganz woanders hab.
Und "sicher" bin ich mir eben nicht - ich hab nur versucht, das Gelesene zu interpretieren
Aber irgendwo muss doch ein gezippter Content angegeben werden, der Client (oder eben der Proxy) muss doch schließlich wissen, ob/wie da was gezipptes daherkommt, oder etwa nicht?

Ich verstehe dann nur die empfohlene Gegenmaßnahme wie "cgi-bin und ? nicht cachen" nicht. Denn müßte man dann nicht genauso alle ".php"-Seiten in die
RegExp aufnehmen ?
Viel schlimmer noch ist IMHO ja der Unterschied bei GET/POST: [...]

Wie gesagt, ich hab ganz ehrlich von GET/POST und sonstigen Aufrufen herzlich wenig Ahnung - aber ich hab meinem Proxy daheim auch das Caching von "?"- und ".php"-Aufrufen abdrehen müssen, da ich immer alte Seiten zurückbekommen hab.
Ist aber kein SQUID sondern Wingate. Es klang nur eben aufgrund meiner Beobachtungen sehr vernünftig.

Vielleicht nicht sehr hilfreich, aber eben meine Interpretation des Ganzen.

Re(2): Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Tue, 01 May 2007 08:24:08 GMT

Hi Glock !

Danke mal für dein Posting...

Nur habe ich das ganz anders interpretiert als Du .


#       Many servers have broken support for on-the-fly Content-Encoding,
#       returning the same ETag on both plain and gzip:ed variants.
#       Vary replies matching this access list will have the cache split
#       on the Accept-Encoding header of the request and not trusting the
#       ETag to be unique.

... das klang für mich überhaupt nicht nach Encoding im Sinne von Zeichensätzen - insbesondere wegen on-the-fly Content-Encoding, returning the same ETag on both plain and gzip:ed variants..
Das klang für mich nach transparentem zippen, weil sie sich ja später auch auf mod_zip bezogen... Sicher, daß Du da recht hast ?

Und das mit dem "?"-Parameter - bleibt mir unklar.
Ich teile deine Position, daß dynamischer Content (insbesondere wenn er nicht nach Usereingaben deterministisch ist sondern beispielsweise zeitabhängig ist) ein Problem für Proxies darstellen kann bzw. muß.

Ich verstehe dann nur die empfohlene Gegenmaßnahme wie "cgi-bin und ? nicht cachen" nicht. Denn müßte man dann nicht genauso alle ".php"-Seiten in die RegExp aufnehmen ?

Viel schlimmer noch ist IMHO ja der Unterschied bei GET/POST:
Bei GET-Aufrufen (also mit "?") haben wir ja den Vorteil, daß die Parameterliste in der URL mitkommt - und die Aufrufe "xxx.porn.at?girl=20" und "xxx.porn.at?girl=30" zwei verschiedene Seiten für den Squid sind - und er die wohl eher cachen dürfte als bei einem POST-Request auf "xxx.porn.at" wo also Post-Variable "girl=40" mitkommt...

Aber nochmal zurück zu dem generellen "Dynamischen Content"-Problem:
Bei meinen Webseiten setze ich die nocache-Pragmas... Die ja SQUID hoffentlich berücksichtigt. Machen das nicht alle ? Denn wenn das alle machen, könnte man auf die Excludes via "cgi-bin" und "?" verzichten...

Re: Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

Glockman — Tue, 01 May 2007 00:06:44 GMT

Hi!

Ohne jetzt mit Apache, SQUID und Webaufrufen im Allgemeinen vertraut zu sein würde ich trotzdem mal sagen:

1) ETags werden wohl Tags sein die angeben, ob der Inhalt jetzt ein bestimmtes encoding hat oder nicht ("Encoding-Tag"); das "Vary replies" ist im Zusammenhang mit dem restlichen Text zu sehen und könnte sinngemäß soviel wie "Auf diese ACL zutreffende abweichende Antworten (vary replies) teilen den Cache beim Erhalt des Accept-Encoding Headers des Aufrufs; der Cache misstraut der Eindeutigkeit des ETag" heißen.

2) Da geht es imho um den Gegenserver; da wirst Du nichts machen können, wenn der Server an den der Proxy den Request schickt eben ein falsches ETag liefert und Dein SQUID sich dann nicht mehr auskennt (oder was auch immer die letztendliche Konsequenz aus dem Misstrauen ist).

3) Ich würde sagen, dass diese "?"-Parameter durchaus problematisch werden können, wenn irgendwas dynamisch sein muss, im Cache jedoch ein alter Eintrag vorhanden ist. In dem Fall macht ein direkter Neuabruf (oder besser noch: ein nicht-caching von solchen Anfragen) durchaus Sinn.

hth,

Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Mon, 30 Apr 2007 20:36:53 GMT

Habe den neuen SQUID Version 2.6.STABLE12 ausprobiert.... Hatte bisher 2.5.

Dabei fiel mir eine neue Config-Option auf:


#  TAG: broken_vary_encoding
#       Many servers have broken support for on-the-fly Content-Encoding,
#       returning the same ETag on both plain and gzip:ed variants.
#       Vary replies matching this access list will have the cache split
#       on the Accept-Encoding header of the request and not trusting the
#       ETag to be unique.
#
# Apache mod_gzip and mod_deflate known to be broken so don't trust
# Apache to signal ETag correctly on such responses
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

So.... Und hier versteh' ich Bahnhof und brauche Hilfe:
1) "Vary replies" - was sind die ?
2) Wenn SQUID einem Apache defaultmäßig bei mod_deflate bzw. mod_gzip nicht mehr traut... Was bedeutet das im Detail ? Kann das bedeuten, daß man beim Apachen beide deaktivieren sollte, damit die SQUIDs bei den Aufrufern sich leichter tun ???

Eine Frage hätte ich noch, die mich schon bei 2.5 beschäftigte:


#  TAG: hierarchy_stoplist
#       A list of words which, if found in a URL, cause the object to
#       be handled directly by this cache.  In other words, use this
#       to not query neighbor caches for certain objects.  You may
#       list this option multiple times. Note: never_direct overrides
#       this option.
#We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

Sollte man das echt machen ?
Der Gedanke ist ja an sich klar - nur sind halt echt viele Seiten voll mit GET-Paras (und daher "?")... Beispielsweise derstandard.at....

Und wieso sollten eigentlich GET-Parameter "Uncachewürdiger" sein als wenn Seiten mit POST-Parametern (also ohne "?") gefüllt werden ???

Apache-Probs durch SQUID enthüllt ? Auswirkung auf Apache ?

googleDork — Mon, 30 Apr 2007 20:36:53 GMT

Habe den neuen SQUID Version 2.6.STABLE12 ausprobiert.... Hatte bisher 2.5.

Dabei fiel mir eine neue Config-Option auf:


#  TAG: broken_vary_encoding
#       Many servers have broken support for on-the-fly Content-Encoding,
#       returning the same ETag on both plain and gzip:ed variants.
#       Vary replies matching this access list will have the cache split
#       on the Accept-Encoding header of the request and not trusting the
#       ETag to be unique.
#
# Apache mod_gzip and mod_deflate known to be broken so don't trust
# Apache to signal ETag correctly on such responses
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

So.... Und hier versteh' ich Bahnhof und brauche Hilfe:
1) "Vary replies" - was sind die ? Was sind ETags ?
2) Wenn SQUID einem Apache defaultmäßig bei mod_deflate bzw. mod_gzip nicht mehr traut... Was bedeutet das im Detail ? Kann das bedeuten, daß man beim Apachen beide deaktivieren sollte, damit die SQUIDs bei den Aufrufern sich leichter tun ???

Eine Frage hätte ich noch, die mich schon bei 2.5 beschäftigte:


#  TAG: hierarchy_stoplist
#       A list of words which, if found in a URL, cause the object to
#       be handled directly by this cache.  In other words, use this
#       to not query neighbor caches for certain objects.  You may
#       list this option multiple times. Note: never_direct overrides
#       this option.
#We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?