Apache und POST auf "statische" Ressourcen

[wahsaga]

hi,

ich möchte gern http://example.org/blubb als statische Ressource bereithalten, um bei GET-Requests Caching und alles was dazugehört dem Apachen zu überlassen, anstatt es selbst zu implementieren. (/blubb existiert also als physische Datei, und wird per ForceType als text/html deklariert.)

Nun möchte ich aber die Möglichkeit haben, per POST Formulardaten an die selbe Ressource zu schicken, mit denen dann diese aktualisiert wird - also die Datei neu geschrieben.
Also wollte ich POST-Requests mittels mod_rewrite auf ein Script umleiten - aber da spielt Häuptling Ich-weiss-besser-was-gut-für-dich-ist nicht mit: 405 Methode Not Allowed.

Das scheint so definiertes und gewolltes Verhalten zu sein -
"You can not POST to a normal HTML file; the operation has no meaning."

Ich will ja aber auch nicht zum HTML file POSTen, sondern zum meinem Script - und that operation has für mich sehr wohl a meaning.
Das interessiert aber leider den Apachen nicht - sein Abwehrmechanismus setzt sich da schon in Gange, bevor ich mittels mod_rewrite eine Chance bekomme Umzuleiten.

Es lässt sich zwar umgehen, in dem ich für GET auf noch eine Regel bereitstelle - und /blubb nicht physisch vorhalte, sondern bspw. blubb.dat oder auch blubb.htm, und darauf umschreibe.
Aber wenn ich mir im RewriteLog anschaue, wie viel Zirkus da dann für einen einzelnen simplen GET-Request abläuft, ist das auch nicht gerade perfomant.

Alternativ zum Umschreiben bei Method=GET könnte ich auch noch MultiViews nutzen - dann muss die physische Datei aber eine Endung wie .htm haben, .dat o.ä. mag er dann nicht finden. Das löst dann aber u.a. wieder Vary-Header im Response aus, was auch nicht sein sollte.

Gibt es keine Möglichkeit, dem Apachen klar zu machen, dass m.E. POST auf eine statische Ressource unter solchen Umständen, wo ich den POST-Request "abfangen" und an ein Script weiterleiten möchte, doch sinnvoll sein und "a meaning" haben könnte?

Sonst muss ich das wohl doch über unterschiedliche URLs lösen, was ich aber eigentlich vermeiden wollte.

gruß,
wahsaga

[Christian Seiler]

Hallo wahsaga,

Gibt es keine Möglichkeit, dem Apachen klar zu machen, dass m.E. POST auf eine statische Ressource unter solchen Umständen, wo ich den POST-Request "abfangen" und an ein Script weiterleiten möchte, doch sinnvoll sein und "a meaning" haben könnte?

Ohne es selbst getestet zu haben, ich könnte mir vorstellen, dass eines (oder beides) von folgenden beiden Dingen funktioniert:

* RewriteRule für die Resource in <Limit POST>-Block
 * Mittels RewriteCond %{REQUEST_METHOD} abfragen.

Viele Grüße,
Christian

[wahsaga]

hi,

Ohne es selbst getestet zu haben, ich könnte mir vorstellen, dass eines (oder beides) von folgenden beiden Dingen funktioniert:

* RewriteRule für die Resource in <Limit POST>-Block
* Mittels RewriteCond %{REQUEST_METHOD} abfragen.

Letzteres hatte ich natürlich schon, das alleine half aber nicht, weil ich per <Files>-Direktive und ForceType dafür gesorgt hatte, dass endungslose Dateien wie /blubb als text/html ausgeliefert werden - und da fuhr mir der Apache mit seinem 405 in die Parade, offenbar noch bevor meine RewriteCond auf Methode=POST und die zugehörige RewriteRule etwas ausrichten konnten.

Du hast mich jetzt aber auf die Idee gebracht, ForceType stattdessen in <Limit GET> zu kapseln - und damit "funzt" es.

<Limit POST> um RewriteCond und -Rule kann ich mir allerdings wohl sparen, denn laut RewriteLog werden die damit trotzdem auch bei GET-Requests ausgewertet.

Trotzdem Danke für den Denkanstoss, damit ist mein Problem offenbar gelöst.

gruß,
wahsaga

[wahsaga]

hi,

ich möchte gern http://example.org/blubb als statische Ressource bereithalten, um bei GET-Requests Caching und alles was dazugehört dem Apachen zu überlassen [...]
Nun möchte ich aber die Möglichkeit haben, per POST Formulardaten an die selbe Ressource zu schicken, mit denen dann diese aktualisiert wird - also die Datei neu geschrieben.

Wie verhält es sich dabei eigentlich mit File Locking?

Wenn ich Auslieferung und Generierung von Dateinhalten beide in PHP abbilde, kann ich mittels flock() ja auf Prozessebene entsprechend Sperren.

Wie sieht das aus, wenn Apache die Dateien ausliefert, ich sie aber per PHP von Zeit zu Zeit neu generieren möchte?

Bewirkt da ein Locking in PHP beim Schreiben irgendwas?
Dann müsste der Apache ja ein Analogon zum LOCK_SH von PHPs flock() beim Lesen der Dateien erzeugen - und die beiden sich darüber auch noch verständigen.

Ist das irgendwie (und nicht allzu komplex) möglich, vielleicht bereits implementiert?
Oder habe ich da keine Chance?

Ob PHP als Apache-Modul oder CGI eingebunden ist, könnte da natürlich noch relevant sein. Mir ginge es mehr um die Einbindung als Modul.

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

Wie sieht das aus, wenn Apache die Dateien ausliefert, ich sie aber per PHP von Zeit zu Zeit neu generieren möchte?

Wie lange dauert der Generierprozess und spielt diese Zeit praktisch eine Rolle, bei der erwarteten Zugriffsrate? Eine Möglichkeit, diese Änderungszeit recht gering zu halten, wäre, den neuen Inhalt in einer temporären Datei zu erstellen und diese durch Umbenennen an die Stelle der alten, gelöschten Datei zu befördern.

echo "$verabschiedung $name";

[wahsaga]

hi,

Wie lange dauert der Generierprozess und spielt diese Zeit praktisch eine Rolle, bei der erwarteten Zugriffsrate?

Die Zeit beim Schreiben auf Platte dürfte kaum ins Gewicht fallen, und die Zugriffraten auch alles andere als enorm werden.
Es ging mir eher um die Theorie, als um die Praxis - ob es da eine Möglichkeit gibt, das möglichst sauber und sicher abzubilden.

Eine Möglichkeit, diese Änderungszeit recht gering zu halten, wäre, den neuen Inhalt in einer temporären Datei zu erstellen und diese durch Umbenennen an die Stelle der alten, gelöschten Datei zu befördern.

Ich hatte sowieso lediglich ans Schreiben des in einer Variable gesammelten neuen Inhalts per file_put_contents "in einem Rutsch" gedacht (Umfang wird sich im Bereich von maximal ein paar Dutzend KB bewegen) - denkst du, dass man da mit einer temporären Datei und Umbenennen noch was "rausholen" könnte?

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

Ich hatte sowieso lediglich ans Schreiben des in einer Variable gesammelten neuen Inhalts per file_put_contents "in einem Rutsch" gedacht (Umfang wird sich im Bereich von maximal ein paar Dutzend KB bewegen) - denkst du, dass man da mit einer temporären Datei und Umbenennen noch was "rausholen" könnte?

Bei den heutigen Zugriffszeiten der Hardware wird der Unterschied bei der Dateigröße kaum ins Gewicht fallen, aber Umbenennen ist nur eine kleine Änderung in der Verzeichnisverwaltung. Solange nicht Tonnen von Dateien in diesem Verzeichnis liegen und die Verwaltung selbiger deutlich Zeit in Anspruch nimmt ...
Dies sind aber nur meine Gedankengänge, da ich mich mit den Gegebenheiten der Dateisysteme nicht näher auskenne.

echo "$verabschiedung $name";

[wahsaga]

hi,

aber Umbenennen ist nur eine kleine Änderung in der Verzeichnisverwaltung.

Das ist ein plausibles Argument, danke.

Dies sind aber nur meine Gedankengänge, da ich mich mit den Gegebenheiten der Dateisysteme nicht näher auskenne.

Na gut - sagen wir es klingt zumindest nach einem plausiblen Argument :-)

gruß,
wahsaga

[迪拉斯]

Hey,
Apache lockt die Dateien bei der Auslieferung nicht. Die Funktionalität ist auch nicht vorgesehen. Mit mod_perl oder sonstigem Zugriff auf das Apache-API kannst du einen FixupHandler, welcher Dateien lockt, leicht nachrüsten.