nicht angemeldet
Apache 2.2.0 auf Linux mit einem <Limit>-, <LimitExpect>-Problem
Moaj'ns,
auf einem GNU/Linux (64bit) habe ich mir einen Apache 2.2.0 kompiliert und scheitere nun daran die HTTP-Methoden zu beschränken. In der httpd.conf habe ich folgendes aufgenommen:
<Directory />
Options FollowSymLinks
AllowOverride None
Order Deny,Allow
Deny from all
<LimitExcept GET>
Order Deny,Allow
Deny from all
</LimitExcept>
</Directory>
Bei einem Apache 1.3.x führt ein POST-Request bei dieser Konfiguration zu etwa folgendem Response-Header:
HTTP/1.1 403 Forbidden
Date: Fri, 20 Jan 2006 20:55:12 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Korrekter wäre zwar eine Status 405, aber das eigentliche Ziel - Abbruch der Anfrageverarbeitung - wird erreicht.
Leider nicht beim neuen Apache 2.2.0:
HTTP/1.1 200 OK
Date: Fri, 20 Jan 2006 20:58:23 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 1201
Connection: close
Content-Type: text/html; charset=iso-8859-1
Per Post übergebene Daten werden dennoch an Scripte weitergereicht, auch ein OPTIONS-Request zeigt, daß die Konfiguration zum Teil keine Wirkung entfaltet:
HTTP/1.1 200 OK
Date: Fri, 20 Jan 2006 21:03:09 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 1425
Connection: close
Content-Type: text/html; charset=iso-8859-1
Es wird also kein "Allow" gesendet, aber Status 200 ist mir jedenfalls nicht "OK".
Folgende Module sind eingebunden:
core_module (static)
authn_file_module (static)
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
auth_basic_module (static)
auth_digest_module (static)
dumpio_module (static)
include_module (static)
deflate_module (static)
log_config_module (static)
logio_module (static)
expires_module (static)
headers_module (static)
setenvif_module (static)
ssl_module (static)
mpm_worker_module (static)
http_module (static)
mime_module (static)
dav_module (static)
dav_fs_module (static)
negotiation_module (static)
dir_module (static)
alias_module (static)
so_module (static)
php5_module (shared)
Weiß jemand Rat, oder ist von einem Bug auszugehen?
Gruß aus Berlin!
eddi
-
hallo eddi,
Per Post übergebene Daten werden dennoch an Scripte weitergereicht, auch ein OPTIONS-Request zeigt, daß die Konfiguration zum Teil keine Wirkung entfaltet
Es wird also kein "Allow" gesendet, aber Status 200 ist mir jedenfalls nicht "OK".Doch, 200 ist bei einem POST durchaus sehr ok. Du hast ja lediglich für GET angegeben, daß das nicht ok sein soll, alle anderen müßten also völlig problemlos funktionieren. Also entfaltet in diesem Fall deine Konfiguration absolut korrekterweise die gewünschte Wirkung.
Folgende Module sind eingebunden:
Wenig interessant in diesem Zusammenhang ...
Lektüre: http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept und http://httpd.apache.org/docs/2.2/mod/core.html#limit
Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Per Post übergebene Daten werden dennoch an Scripte weitergereicht, auch ein OPTIONS-Request zeigt, daß die Konfiguration zum Teil keine Wirkung entfaltet
Es wird also kein "Allow" gesendet, aber Status 200 ist mir jedenfalls nicht "OK".Doch, 200 ist bei einem POST durchaus sehr ok. Du hast ja lediglich für GET angegeben, daß das nicht ok sein soll, alle anderen müßten also völlig problemlos funktionieren. Also entfaltet in diesem Fall deine Konfiguration absolut korrekterweise die gewünschte Wirkung.
Lektüre: http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept und http://httpd.apache.org/docs/2.2/mod/core.html#limit
danke für Deinen gutgemeinten Versuch hier etwas verstehen zu wollen. Da die von Dir anempfohlene Lektüre anscheinend bei einigen Leuten zu verwirrensten Äußerungen führt, erkläre ich hier _sehr_ _gerne_ mittels Zitat, was der Unterschied zwischen
<Limit>und<LimitExpect>ist:Zitat
<LimitExcept> und </LimitExcept> werden dazu verwendet,
eine Gruppe von Anweisungen zur Zugriffskontrolle zu-
sammenzufassen, die dann auf jede HTTP-Methode angewen-
det werden, die[ Einfügung: "!!!!!!11111" ]
nicht
[ Einfügung: "!!!!!!11111" ]
als Argument angegeben ist. D.h. dies ist das Gegenteil
des <Limit>-Containers und kann zur Steuerung von Stan-
dard- und nicht-Standard-/unbekannten Methoden verwendet
werden.
Zitatende.Ich habe und bin dann fertig!
Gruß aus Berlin!
eddi
-
-
Hallo,
auch wenn Christophs Antwort auf den ersten Blick plausible sein mag, sie ist leider falsch.
Da ich die gleiche Frage ohne Rückmeldungen auch schon an die Mailingliste Apaches gesandt habe, bitte ich wenigsten um eine Bestätigung, ob sich dieses Fehlverhalten des Server auch bei anderen reproduzieren läßt, oder ob es doch in der Modulkonstellation begründet liegt.Gruß aus Berlin!
eddi-
hallo eddi,
ob es doch in der Modulkonstellation begründet liegt.
Nein. <Limit> und <LimitExcept> sind "core"-Bestandteile, wie übrigens alle Container. Wenn du "Order" und "Allow from" einsetzen möchtest, brauchst du mod_authz_host, und das hast du nach deinem OP bereits statisch eingebunden.
Grüße aus Berlin
Christoph S.
-
Nabend Christoph,
ob es doch in der Modulkonstellation begründet liegt.
Nein. <Limit> und <LimitExcept> sind "core"-Bestandteile, wie übrigens alle Container. Wenn du "Order" und "Allow from" einsetzen möchtest, brauchst du mod_authz_host, und das hast du nach deinem OP bereits statisch eingebunden.
meine Überlegung geht eher genn mod_dav da hier zusätzliche Requestmethoden definiert werden. Nur wollte ich mir vor einem Bug-Bericht die Arbeit ersparen unter verschiedenen Modulkonstellationen auszustesten, ob es ein Fehler eines Moduls ist, oder ob hier ein grundsätzlicher Fehler vorliegen könnte.
Gruß aus Berlin!
eddi-
hallo eddi,
meine Überlegung geht eher genn mod_dav
Davon hast du bisher nichts gesagt. Mit dem, was die Container <Limit> und <LimitExcept> bewirken (sollen), hat mod_dav aber so gut wie gar nichts zu tun.
da hier zusätzliche Requestmethoden definiert werden.
Wenn du _das_ prüfen möchtest, verschachtelst du eben deine Container. Schematisch in so einer Form:
<ifModule mod_dav.so>
<LimtExcept GET>
...
</LimtExcept>
</ifModule>Nur wollte ich mir vor einem Bug-Bericht die Arbeit ersparen unter verschiedenen Modulkonstellationen auszustesten, ob es ein Fehler eines Moduls ist, oder ob hier ein grundsätzlicher Fehler vorliegen könnte.
Du weißt, daß du natürlich die jeweiligen CHANGELOG gründlich durchsehen solltest, wenn du experimentieren möchtest?
Grüße aus der kältestarren Nachbarschaft (minus 14°C im Moment)
Christoph S.
-
Re:
da hier zusätzliche Requestmethoden definiert werden.
Wenn du _das_ prüfen möchtest, verschachtelst du eben deine Container. Schematisch in so einer Form:
Christoph, bitte sage mir, was ich falsch mache, daß Du mich nicht verstehen kannst!
Nach RFC 2616 hat ein Webserver auf Requests mit nicht erlaubten Methoden mit dem Status 405 Method Not Allowed zu antworten. Auch ist ein 403 Forbidden denkbar, was die Version 1.3 des Apachen unterstützt.Nur ist ausweislich der extra dafür mitgeposteten Responseheader mit keines der beiden Stati von der Version 2.2.0 geantwortet worden - weder bei der Konfiguration mit <Limit>, noch bei der mit <LimitExpect>.
Nur wollte ich mir vor einem Bug-Bericht die Arbeit ersparen unter verschiedenen Modulkonstellationen auszustesten, ob es ein Fehler eines Moduls ist, oder ob hier ein grundsätzlicher Fehler vorliegen könnte.
Du weißt, daß du natürlich die jeweiligen CHANGELOG gründlich durchsehen solltest, wenn du experimentieren möchtest?
Ich möchte nicht experimentieren, sondern das wir alle bald eine stabile und funktionstüchtige Version 2.2.x habe werden.
Gruß aus Berlin!
eddi-
hallo eddi,
Ich möchte nicht experimentieren, sondern das wir alle bald eine stabile und funktionstüchtige Version 2.2.x habe werden.
Es mag Gründe geben, weshalb es bisher so gut wie keine Distribution gibt, die in ihre distributionsspezifischen Installerpakete die 2.2 aufgenommen haben. Gentoo, das doch sehr viel Wert auf Aktualität legt, bietet über den portage-Tree bisher "nur" einen Apache 2.0.55 an und hat noch nicht einmal eine "ausgeflagte" Testversion für Apache 2.2.x im Angebot. Für FreeBSD gibt es dagegen dagegen einen solchen Port. Was damit zusammenhängen könnte, daß die Apache-Entwickler selbst eben keine Linux- , sondern Unix-Plattformen benutzen.
Apache 2.2.x _ist_ derzeit noch nicht wirklich stabil, trotz Ankündigung - und ganz gegen alle bisherigen Gewohnheiten gibts ja auch noch kein MSI-Archiv für Windows (Die Apachefriends sind da vorgeprescht und haben sich eine 2.2.0 selber kompiliert).
Ich kann da auch nur diverse Glaskugeln befragen. Aber ich würde derzeit noch nicht auf eine 2.2.x setzen (schau dir einfach mal an, was sich in 2.3.x bereits tut). Ähnlich wie es bei 2.0.x erst mit 2.0.49 einigermaßen "stabil" wurde, wird es wohl auch bis 2.2.3x dauern, bis "the best available Version" der Wahrheit einigermaßen nahekommt. Bei aller Liebe also: hab am besten ein bißchen Geduld.
Im übrigen beschäftigt mich das Thema natürlich, da es in der 2.2.x eine "neue Struktur" für die httpd.conf gibt, was meinen Artikel unmittelbar betrifft.
Grüße aus Berlin
Christoph S.
-
-
-
-
-