regexp: Zerlegen einer Zeile mit _zwei_ unbekannten Teil-Mustern

[Michael Schröpl]

Hallo Forum-Leser,

ich schlage mich gerade mit einem Problem herum, für das ich keine
vernünftige Lösung zustande kriege.

Ich habe Zeilen einer Datei (Apache-Log) zu analysieren.
(Das, was ich will, kann ein Standard-Tool wie der Webalizer nicht - also
habe ich mir selbst eines geschrieben - natürlich viel spartanischer.)

Diese Zeile enthält eine Menge definierter Spalten. Die meisten davon sind
zuverlässig whitespace-frei, und der Apache verwendet ja auch Leerzeichen
als Trenner zwischen zwei Spalten.

Nun habe ich aber _zwei_ Spalten, über deren Inhalt ich nicht zuverlässig
etwas aussagen kann:

• den URL der Anforderung (der sollte eigentlich nur URLencoded-Zeichen
    enthalten, aber weit gefehlt: Manche Browser codieren eben _nicht_ alles
    um, und der Apache schreibt gnadenlos den URL ins Log, den er empfangen
    hat, selbst wenn da Steuerzeichen drin wären oder HTML-Code) und
• den UserAgent (da schreiben ja manche Surfer die dollsten Dinge rein -
    auch HTML-Code habe ich darin schon gefunden).

Da stehe ich nun, und möchte diese Zeile zerlegen. Aber wie erkenne ich
jetzt zuverlässig meine Felder?

Wäre es nur _ein_ solches Kamikaze-Feld drin, dann würde ein regular
expression, der ein Muster mit '^' und '$' prüft, per backtracking eine
eventuelle falsche Feld-Zerlegung erkennen und rückgängig machen.
Sinnvollerweise würde ich dieses Feld an den Schluß der Zeile legen, um
es dem Backtracker einfacher zu machen. (Das habe ich mit dem UserAgent
bereits versucht. Wenn sich jetzt noch der URL bändigen ließe ...)

Genau das scheint aber bei _zwei_ dieser Felder nicht möglich zu sein.
Denn _beide_ könnten genau mein Feld-Trennzeichen enthalten.

Ein Beispiel: (IP-Adresse, URL, UserAgent; Trennzeichen sei ein Blank)
  127.0.0.1 http://127.0.0.1/ ein URL mit Leerzeichen Ein UserAgent
Tja, wo hört jetzt der URL auf, und wo fängt der UserAgent an?

Es wird natürlich nicht besser, wenn ich die IP-Adresse in die Mitte lege:
  http://127.0.0.1/ ein URL mit Leerzeichen 127.0.0.1 Ein UserAgent
Theoretisch könnte auch "Leerzeichen" die IP-Adresse sein.

In dem letztgenannten Fall könnte ich mir scheinbar dadurch helfen,
daß ich für die IP-Adresse ein "scharfes" Muster parse, also nicht (\S+),
sondern beispielsweise (\d+.\d+.\d+.\d+). Im obigen Falle würde der
regular expression die IP-Adresse etwas zuverlässiger finden.

Aber wer hindert einen Benutzer daran, ein korrektes Muster einer IP-
Adresse in seinem UserAgent zu senden oder ein solches als Teil eines
URL zu verwenden (sagen wir mal, als QUERY_STRING):
  http://127.0.0.1/ URL mit 127.0.0.1 127.0.0.2 UserAgent
Wo steht jetzt die IP-Adresse? Wo endet der URL, wo beginnt der UserAgent?

Irgendwie fürchte ich, daß meine Aufgabenstellung, die Felder meiner
Zeile zuverlässig zu zerlegen, grundsätzlich unlösbar ist.
Ich bin mir aber der Mächtigkeit von regulären Ausdrücken nicht exakt
genug bewußt, um nicht doch einen Versuch zu starten, hier einen Tip zu
bekommen. Aber auch ein Beweis, daß ich keine Chance habe, würde mir
weiterhelfen - dann kann ich wenigstens guten Gewissens aufgeben.

Momentan behelfe ich mir damit, daß mein Auswertungsprogramm einen
geheimen, relativ komplizierten Feldtrenner verwendet.
Im Sinne der korrekten Verarbeitung ist das natürlich keine Lösung; ich
verstehe die Programmausgabe aber gut genug, um auf einen Blick erkennen
zu können, ob da etwas falsch zugeordnet ist.
Nur leider möchte ich mein Programm weitergeben ... das Problem könnte
also bei einer beliebig großen Benutzermenge in beliebiger Form auftreten.

Hätte ich eine Möglichkeit, die Apache-Protokollierung zu beeinflussen,
beispielsweise um alle Sonderzeichen explizit zu URLencoden, dann wäre
ich gerettet. Das darf aber nicht dadurch geschehen, daß ich beispiels-
weise mod_log_custom umschreibe - es sollte bei _allen_ Apaches funktio-
nieren, nicht nur bei meinem eigenen ...

In der Hoffnung auf einen Geistesblitz grüßt
       Michael

[LanX]

Hi Michael,

verstehe ich dich richtig das du die Sortierung der Spalten vorgeben kannst? (Kenn mich mit Apache nicht aus)

Wie wärs mit AGENT IP URL ?

mit (hingerotzt)

/(\w[\w ]+?) (\d+.\d+.\d+.\d+) (http://[\w ]+)/

fängst du alle Fälle in denen der AGENT nicht die Form 'IP-Muster http://' enthält, was sehr krank wäre.
Falls doch würden dann IP und AGENT in $3 stecken

Mit ner Sicherheitsabfrage ob 'IP-Muster http://' nochmal in $3 steckt erkennst du diesen seltenen Fehlerfall ohne ihn korrigieren zu können, denn 'IP-Muster http://' könnte auch aus der URL stammen.

Aber du weißt wenigstens wie groß der Fehler ist, und
dieser Fehler erscheint mir am unwahrscheinlichsten.
Solange er eine Toleranzschwelle nicht überschreitet
ignoriere ihn (nimm die wahrscheinlichste Annahme wie bei fehlerkorrigierenden Codes)

Falls du noch mehr verläßliche Spalten zur Verfügung hast quetsche sie zwischen AGENT und IP, dann senkst du
die Wahrscheinlichkeit weiter (sind URLs nicht sowieso
auf 256 Zeichen begrenzt? Dann könntest Du auch irgendwann 100%ige Sicherheit haben!)

Hoffe ich konnte dir weiterhelfen :)

Tschau
  Rolf

[Michael Schröpl]

Hi Rolf,

verstehe ich dich richtig das du die Sortierung der Spalten vorgeben
kannst? (Kenn mich mit Apache nicht aus)

Ja, das kann ich. In meinem realen Einsatzfall sind es übrigens acht Felder,
von denen ich bei allen außer URL und UserAgent das Format sehr genau kenne.

(sind URLs nicht sowieso auf 256 Zeichen begrenzt?)

Nein - auch wenn HTTP 'empfiehlt', nicht mehr vorauszusetzen.

Viele Grüße
      Michael

[Sven Rautenberg]

Moin!

Diese Zeile enthält eine Menge definierter Spalten. Die meisten davon sind
zuverlässig whitespace-frei, und der Apache verwendet ja auch Leerzeichen
als Trenner zwischen zwei Spalten.

Und die Zeilen für User-Agent etc. verwenden Anführungsstriche, um den String von trennenden Whitespaces zu trennen. Du hast also eine eindeutige Zuordnung.

Jedenfalls ist das bei meinen Apache-Logfiles so, und die sind "combined", was eines der Standardformate ist.

Es kann durchaus sein, daß das Log-Zeilenformat explizit die Anführungsstriche mit angibt - dann solltest du das auch machen. Oder (falls dir Anführungsstriche nicht sicher genug sind) ein anderes Zeichen (bzw. Zeichenkombination) dafür verwenden.

- Sven Rautenberg

[LanX]

Hi

Diese Zeile enthält eine Menge definierter Spalten. Die meisten davon sind
zuverlässig whitespace-frei, und der Apache verwendet ja auch Leerzeichen
als Trenner zwischen zwei Spalten.

Und die Zeilen für User-Agent etc. verwenden Anführungsstriche, um den String von trennenden Whitespaces zu trennen. Du hast also eine eindeutige Zuordnung.

Und werden Anführungsstriche die unerlaubter Weise im Agent oder URL
vorkommen escaped? Sonst fängt doch Michaels Problem von vorne an! :(

Bye
  rolf

[Sven Rautenberg]

Moin!

Und werden Anführungsstriche die unerlaubter Weise im Agent oder URL
vorkommen escaped? Sonst fängt doch Michaels Problem von vorne an! :(

Deswegen schrieb ich: "Kombination von Trennzeichen".

Abgesehen davon: Man kann die Logdaten auch in mehrere Dateien aufsplitten. Dann ist pro Zugriff nur eine Zeile zuständig, die ab einem gewissen Zeichen komplett für die Browserinformation genutzt werden kann - völlig unabhängig von irgendwelchen Trennzeichen. Die Zuordnung der einzelnen Dateieinträge dürfte durch ein identisches Datum in jeder einzelnen Datei klappen.

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Abgesehen davon: Man kann die Logdaten auch in mehrere Dateien
aufsplitten. Dann ist pro Zugriff nur eine Zeile zuständig, die ab
einem gewissen Zeichen komplett für die Browserinformation genutzt
werden kann - völlig unabhängig von irgendwelchen Trennzeichen.

das wäre für die Benutzer allerdings lästiger.

Außerdem: Wie sicher kann ich sein, daß auf einem Multi-CPU-System ein
Logeintrag in _mehrere_ Logfiles eine atomare Operation ist?
Wenn da zwei Prozessoren anfangen, quasiparallel Zeile zu schreiben,
dann geht mir der Bezug verloren.

Die Zuordnung der einzelnen Dateieinträge dürfte durch ein identisches
Datum in jeder einzelnen Datei klappen.

Schön wär's ja - aber mehrere Requests pro Sekunde sind ein völlig normaler
Einsatzfall, und genauer als Sekunde löst der Apache die Uhrzeit nicht auf.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Rolf,

Ich habe mit verschiedenen Browsern mal URLs mit Leerzeichen drin in die
URL-Zeile getippt und im access_log nachgesehen, was passiert.
Der M$IE 5.0 url-encoded das Leerzeichen sofort (ersetzt es sogar in der
URL-Zeile im Browser), aber beispielsweise bei Netscape 3 geht das Leer-
zeichen gnadenlos durch - bis ins Logfile.

Und werden Anführungsstriche die unerlaubter Weise im Agent oder URL
vorkommen escaped? Sonst fängt doch Michaels Problem von vorne an! :(

Eben - das werden sie leider nicht:

127.0.0.1 - - [24/Feb/2002:02:52:44 +0100] "GET /"1"2"3"4"5 HTTP/1.0" 403 279

Apache ist da gnadenlos. :-(

Mir ist bewußt, daß ich durch hinreichend viele Felder das "faken" immer
schwerer machen kann. Aber wenn ich "A X1 X2 X3 X4 B" als Felderliste habe,
wobei A und B die Felder mit unbekanntem Inhalt sind, dann kann eben A am
Ende UND B am Anfang ein Muster enthalten, das genau auf alle X-Felder
matcht. Und dann ist die Feldzerlegung anscheinend immer mehrdeutig ...

So weit war ich mit meinen Überlegungen, als ich diesen Thread eröffnet
hatte.

Viele Grüße
      Michael

[LanX]

Hi Michael

Mir ist bewußt, daß ich durch hinreichend viele Felder das "faken" immer
schwerer machen kann. Aber wenn ich "A X1 X2 X3 X4 B" als Felderliste habe,
wobei A und B die Felder mit unbekanntem Inhalt sind, dann kann eben A am
Ende UND B am Anfang ein Muster enthalten, das genau auf alle X-Felder
matcht. Und dann ist die Feldzerlegung anscheinend immer mehrdeutig ...

Da sind wir uns einig. Aber wenn es nicht mit einem neuen Trennerzeichen

oder \n klappt, dann läßt sich das Problem mit RegExp nicht umgehen. Deswegen mein

Vorschlag die Fehlerwahrscheinlichkeit zu minimieren und ähnlich der
Codierungstheorie den Fehler zu erkennen und die wahrscheinlichste
Annahme zu nehmen. Signifikante Fehlerfälle dürften dann nicht wahrscheinlicher
sein als die unvermeindlichen Bugs die eh in jdm Programm stecken. (Ein
bißchen Physiker-Philosophie, wenn das Teil länger stabil läuft als
das Universum alt wird, was solls ...)

Allerdings eine Apache-Lösung mit verläßlichem Trennerzeichen ist weit
unkomplizierer zu realisieren und vorzuziehen!

Tschau
   Rolf

[Michael Schröpl]

Hi Rolf,

Allerdings eine Apache-Lösung mit verläßlichem Trennerzeichen ist weit
unkomplizierer zu realisieren und vorzuziehen!

Die hätte aber die Nachteile, daß sie erstens inkompatibel zu den bisherigen Formaten ("common" bzw. "combined") wäre (also vom Webalizer nicht mehr verstanden würde) und sich zweitens erst mal allgemein durchsetzen müßte, bevor ich dann darauf aufbauend ein Programm für den webweiten Einsatz mich zu schreiben trauen dürfte.

Viele Grüße
      Michael
(der inzwischen den '#' als "vorläufig endgültige" Lösung eingebaut hat ;-)

[LanX]

Hi Michael

Die hätte aber die Nachteile, daß sie erstens inkompatibel zu den bisherigen Formaten ("common" bzw. "combined") wäre (also vom Webalizer nicht mehr verstanden würde) und sich zweitens erst mal allgemein durchsetzen müßte, bevor ich dann darauf aufbauend ein Programm für den webweiten Einsatz mich zu schreiben trauen dürfte.

Dachte ich mir dass du eine Neukonfiguration des Trenners nicht vorschreiben kann.

Mal unter uns, wie hoch schätzt du die Wahrscheinlichkeit ein dass im
AGENT die Folge X1-X8 auftritt, und welcher Schaden würde so eine
Fehlinterpretation (vor der du auch noch gewarnt wirst) auslösen?
Dann vergleiche dieses mit der Wahrscheinlichkeit das irgendein anderer
Fehler auftritt, einfach weil es keine 100%ig fehlerfreien Programme gibt
und weil es sich kaum jmd leisten kann 100%ige Tests zu fahren.

Das Universum beruht auf Wahrscheinlichkeiten, warum also nicht auch unsere
(hoffentlich fehlertoleranten) Programme?

Tschuess
  Rolf

[Michael Schröpl]

Hi Rolf,

Dachte ich mir dass du eine Neukonfiguration des Trenners nicht
vorschreiben kannst.

Für mein eigenes Log-Format kann ich das durchaus vorschreiben. Das finde
ich schon schlimm genug (ist allerdings nicht zu vermeiden, weil ich ganz
andere Felder brauche als "combined").

Ich will aber niemandem vorschreiben, dafür zusätzlich auch noch einen
gepatchten Apache verwenden zu müssen - das macht keiner mit.

Mal unter uns, wie hoch schätzt du die Wahrscheinlichkeit ein dass im
AGENT die Folge X1-X8 auftritt, und welcher Schaden würde so eine
Fehlinterpretation (vor der du auch noch gewarnt wirst) auslösen?

Nicht hoch. Aber das dachte ich auch, als ich ein Trennzeichen verwendet
hatte, von dem ich 'wußte', daß es nicht auftreten kann, weil es in URLs
URL-encoded werden muß (was aber mindestens ein Browser nicht tut).
Deshalb möchte ich ja jetzt das geballte Wissen des Forums einsetzen ...

Dann vergleiche dieses mit der Wahrscheinlichkeit das irgendein anderer
Fehler auftritt, einfach weil es keine 100%ig fehlerfreien Programme gibt
und weil es sich kaum jmd leisten kann 100%ige Tests zu fahren.

Bei hinreichend einfachen Aufgabenstellungen gibt es durchaus fehlerfreie
Programme. Und meine Aufgabenstellung kommt mir in dieser Hinsicht eigent-
lich relativ einfach vor.

Das Universum beruht auf Wahrscheinlichkeiten, warum also nicht auch
unsere (hoffentlich fehlertoleranten) Programme?

Möchtest Du wirklich das Niveau von M$ nicht übertreffen? Ich schon. ;-)

Viele Grüße
      Michael

[LanX]

Hi Michael

Das Universum beruht auf Wahrscheinlichkeiten, warum also nicht auch
unsere (hoffentlich fehlertoleranten) Programme?

Möchtest Du wirklich das Niveau von M$ nicht übertreffen? Ich schon. ;-)

Boh! Das nehm ich dir übel! ;)

Ich halts lieber mit dem Niveau von Heisenberg, wenn ein Neutrino deinen
Computer unglücklich trifft, stürzt dein Programm auch ab. Lieferst
du deswegen ne 1 Millionen Kilometer dicke Bleipanzerung mit?

Nicht? Du entäuschst mich, du nimmst also ne Fehlerquelle in Kauf! ;)

Ohne Apache-Patch läßt sich das Problem mathematisch nicht lösen! Aber
Computer sind physikalische Gebilde, die eben den Gesetzen der _Physik_
unterliegen, und somit Wahrscheinlichkeitsüberlegungen! "Gott würfelt"
nämlich!

Das unterscheidet ein Programm auch von einem Beweis, und damit Informatik
von  Mathematik.

Im übrigen, erkennst du ja, wenn das Scanergebnis mehrdeutig ist und kannst darauf
reagieren (Fehlermeldung, Warning, Ignorieren, je nachdem was du vorhast)
Die Wahrscheinlichkeit das X1-X8 im AGENT auftauchen ist IMHO geringer als
das jemand deinen PGP oder SSL-Schutz aushebelt, Sachen denen du täglich vertraust.

M$ hingegen gehorcht ganz anderen Gesetzen, denen des Marketings. Wie wenig Zeit
und Geld muß ich in ein Produkt stecken und kann trotzdem den Markt erobern.
Computer mögen der Physik gehorchen, ihre Nutzer unterliegen aber leider
denen der Biologie, Psycholgie und Soziologie.

Konkret: M$ würde postulieren das keine Leerzeichen vorkommen dürfen und
den schwarzen Peter zu Apache und NS3 schieben. :(

Tschau
   Rolf

[Michael Schröpl]

Hi Rolf,

Ohne Apache-Patch läßt sich das Problem mathematisch nicht lösen!

Mit einem zuverlässigen Trennzeichen schon.
Ich finde den vorgeschlagenen "\n" ja nur häßlich, nicht aber unbrauchbar.
Mathematisch gesehen ist er die Lösung meines Problems, weil er innerhalb
eines HTTP-Headers nicht vorkommen _kann_.

Das unterscheidet ein Programm auch von einem Beweis, und damit
Informatik von Mathematik.

Dann haben wir unterschiedliche Vorstellungen vom Begriff "Informatik".

Im übrigen, erkennst du ja, wenn das Scanergebnis mehrdeutig ist

Ja? Wie denn?
Wenn der regular expression zwei Möglichkeiten zu matchen hat, wie bekomme
ich das mit?

Die Wahrscheinlichkeit das X1-X8 im AGENT auftauchen ist IMHO
geringer als das jemand deinen PGP oder SSL-Schutz aushebelt, Sachen
denen du täglich vertraust.

Ich habe allerdings mein erstes Trennzeichen '|' bereits im täglichen
Betrieb ausgehebelt bekommen ...

Konkret: M$ würde postulieren das keine Leerzeichen vorkommen dürfen und
den schwarzen Peter zu Apache und NS3 schieben. :(

Genau das möchte ich eben nicht. Ich möchte zumindest etwas Besseres als
das Leerzeichen - und herausfinden, welche Möglichkeiten es gibt. Ich muß
keinem Aktionär Rechenschaft über die von mir investierte Zeit in die Lö-
sung dieses (zugegebenermaßen eher ästhetischen) Problems geben.

Sowohl das "\n" als auch das '#' sind Verbesserungen meines bisherigen
Zustands - insofern hat sich der Thread für mich schon gelohnt.

Viele Grüße
      Michael

[LanX]

Hi Michael

Ohne Apache-Patch läßt sich das Problem mathematisch nicht lösen!

Mit einem zuverlässigen Trennzeichen schon.
Ich finde den vorgeschlagenen "\n" ja nur häßlich, nicht aber unbrauchbar.
Mathematisch gesehen ist er die Lösung meines Problems, weil er innerhalb
eines HTTP-Headers nicht vorkommen _kann_.

ich dachte du hättest "\n" als Patch bezeichnet, aber wenns dem Kunden zumutbar
ist, mach es!

Das unterscheidet ein Programm auch von einem Beweis, und damit
Informatik von Mathematik.

Dann haben wir unterschiedliche Vorstellungen vom Begriff "Informatik".

Hmm wenn alle Leute ihre Programme beweisen würden, hätten wir noch Lochkarten.
BTW: ich bin Mathematiker!

Im übrigen, erkennst du ja, wenn das Scanergebnis mehrdeutig ist

Ja? Wie denn?
Wenn der regular expression zwei Möglichkeiten zu matchen hat, wie bekomme
ich das mit?

Hab ich im ersten Post bereits geschrieben, du testest die Matches darauf ab
ob X1-X8 erneut vorkommt.
(AGENT) (X1) ...(X8) (URL)

wenns ein falsches X-muster im AGENT vorkommen, dann stecken die wahren
X im Match der URL, und lassen sich so erkennen. Ein falsches X-Muster im URL würde die
gleiche Fehlermeldung, aber keinen Fehler erzeugen.

Hast Du damals an der TU nicht Codierungstherie bei Tschach gehört?

Bye
  Rolf

[Michael Schröpl]

Hi Rolf,

Ohne Apache-Patch läßt sich das Problem mathematisch nicht lösen!
Ich finde den vorgeschlagenen "\n" ja nur häßlich, nicht aber unbrauchbar.
ich dachte du hättest "\n" als Patch bezeichnet, aber wenns dem Kunden zumutbar ist, mach es!

Mit "patch" meinte ich, den Apache so umzuschreiben, daß er URLs vor
dem Loggen URL-encoded. Dann wäre mein Problem keines mehr.

wenns ein falsches X-muster im AGENT vorkommen, dann stecken die
wahren X im Match der URL, und lassen sich so erkennen.
Ein falsches X-Muster im URL würde die gleiche Fehlermeldung, aber
keinen Fehler erzeugen.

Und was ist, wenn das Muster in _beiden_ steckt (weil es z. B. fünfmal
vorkommt)? Wo ist dann die korrekte Sollbruchstelle? 4:1? 3:2? 2:3? ...

Hast Du damals an der TU nicht Codierungstherie bei Tschach gehört?

Codierungstheorie, ja - Tschach nein.
(Ich glaube, Ganter hieß der Prof, und war Mathematiker ...)

Viele Grüße
      Michael

[LanX]

Hi

Und was ist, wenn das Muster in _beiden_ steckt (weil es z. B. fünfmal
vorkommt)? Wo ist dann die korrekte Sollbruchstelle? 4:1? 3:2? 2:3? ...

Sollbruchstelle sollte 1:n sein, weil IMHO eine dahingehende Manipulation des Agent am unwahrscheinlichsten ist. In der URL hingegen kann ichs mir leider vorstellen, warum sollte nicht jemand auf die Idee kommen Apache-Logs zu posten?

Codierungstheorie, ja - Tschach nein.
(Ich glaube, Ganter hieß der Prof, und war Mathematiker ...)

Ach ja Berhard G., kenn ich gut! Hat sich mal einen _legendären_ Briefwechsel mit Procter&Gamble geliefert.
Die haben Clerasilpackungen mit "Schule ist doof" -Aufklebern verkauft. Auf Nachfrage was das solle meinten
die es spiegele ja die Meinung der Mehrheit wieder.
Ganter schrieb zurück er hätte spontan eine Umfrage bei
11 1/2 herumstehenden Studenten gestartet und "Clerasil
ist Beschiss" spiegele die Meinung der Mehrheit wieder,
deswegen ließe er jetzt entsprechende Aufkleber an der Uni verteilen. Die haben sich vielleicht aufgeregt *g*. Irgendwann kam ein Brief von nem Typen ganz oben in deren Hierarchie der sich dann entschuldigte dass seine Untergebenen leider kein gutes Gespür für Humor hätten. :)

Tschau
  Rolf

[Michael Schröpl]

Hi Rolf,

Ach ja Berhard G., kenn ich gut! Hat sich mal einen _legendären_ Briefwechsel mit Procter&Gamble geliefert.

LOL ...

Viele Grüße
      Michael
(der bei Ganter eine Diplomprüfung über u. a. Lottoscheine gemacht hat - "Diskrete Mathematik" hieß das damals ...)

[LanX]

Hi Michael

(der bei Ganter eine Diplomprüfung über u. a. Lottoscheine gemacht hat - "Diskrete Mathematik" hieß das damals ...)

Jaja, AlltagsMathe ist sein Ding. Eine Vorlesung hieß bei ihm "Kariertes Papier".
B.G. hat IMHO damals auch den DFB angeschrieben um das Verfahren hinter dem
Spielplan zu erfahren. (Irgendwas mit nem permutierenden Gruppoid oder Halbgruppe oder so ...)

Noch ne Story?

Als B.G. mal Dekan war mußte er auch die Erstsemester in der Erstvorlesung
begrüßen. "Mit einigen der Studenten die sie in dieser Woche kennenlernen,
werden sie ein Leben lang befreundet sein! Das Mädchen das in der
Erstvorlesung neben mir saß, ist heute meine Frau!" Leider war ich nicht dabei
aber es muß göttlich gewesen sein wie die ganzen Erstis auf einmal hektisch
angefangen haben nach links und rechts zu gucken, teilweise extrem geschockt
der Zukunft harrend *g*...

Cheers
  Rolf

[Achim Schrepfer]

Hi Michael,

Mit "patch" meinte ich, den Apache so umzuschreiben, daß er URLs vor
dem Loggen URL-encoded. Dann wäre mein Problem keines mehr.

aber woher weisst Du, welche Zeichen der Browser nicht schon encoded hat? Aus Deinen vorigen Postings ging ja hervor, dass in diesem Zusammenhang eine ziemliche Willkür seitens der Browser herrscht. Und wenn ein Browser nur eine Teilmenge an Sonderzeichen URL-encoded, dann wird es schwer werden, herauszufinden, welche Zeichen noch zum encoden übrig sind, oder?

Viele Grüsse
Achim

PS: heisst das eigentlich "encodet" oder "encoded" *grübelüberdenglisch*

[Klaus Mock]

Hallo Michael,

Ich möchte zumindest etwas Besseres als das Leerzeichen - und herausfinden, welche Möglichkeiten es gibt.

Dann könnte ich noch \t anbieten;-)
Das in den URL bzw UserAgent-String reinzubringen ist zumindest mit einem interaktiven Browser nicht, bzw. nur mutwillig (gibts denn überhaupt eine Möglichkeit?), machbar.

Grüße
  Klaus

[Michael Schröpl]

Hi Klaus,

Dann könnte ich noch \t anbieten;-)

Hey! Das ist ja wie im Supermarkt hier! :-)

Eigentlich habe ich ja auch gegen TABs so meine Vorbehalte (was habe ich mir nicht schon Dateien zerschossen, wo TAB ein Semantikträger war, mein Editor aber automatisch in Leerzeichen konvertiert).
Aber für den vorliegenden Fall gefällt mit das TAB-Zeichen bisher am besten - danke!

Das in den URL bzw UserAgent-String reinzubringen ist zumindest
mit einem interaktiven Browser nicht, bzw. nur mutwillig (gibts
denn überhaupt eine Möglichkeit?), machbar.

Den UserAgent zu verstehen habe ich nicht vor - da schreiben irgendwelche Leute irgendwas rein.
Solange ich den URL "bändigen" kann, habe ich gewonnen.

Viele Grüße
      Michael

[Klaus Mock]

Hallo Michael,

Eigentlich habe ich ja auch gegen TABs so meine Vorbehalte (was habe ich mir nicht schon Dateien zerschossen, wo TAB ein Semantikträger war, mein Editor aber automatisch in Leerzeichen konvertiert).

Dann solltest Du Dir aber schleunigst einen anderen Editor suchen. Ich persönlich mag keine Programme, welche ungefragt irgendwas ummodeln, nur weil sie glauben, es doch besser zu wissen. Das ist auch der Grund, warum ich vi jedem emacs vorziehe, abgesehen davon, daß mir der sowieso zu hoch ist;-)

Das in den URL bzw UserAgent-String reinzubringen ist zumindest
mit einem interaktiven Browser nicht, bzw. nur mutwillig (gibts
denn überhaupt eine Möglichkeit?), machbar.

Den UserAgent zu verstehen habe ich nicht vor - da schreiben irgendwelche Leute irgendwas rein.
Solange ich den URL "bändigen" kann, habe ich gewonnen.

Ich meinte ja nur, daß es theoretisch die Möglichkeit gibt, daß jemand auch einen TAB in den URL unterbringt. Ich habs mal mit TELNET probiert, und es ging. Aber das abdecken zu wollen steht IMHO in keiner sinnvollen Kosten/Nutzen-Relation. Irgendwann sollte da Schluß sein.

Grüße
  Klaus

[Michael Schröpl]

Hi Klaus,

Dann solltest Du Dir aber schleunigst einen anderen
Editor suchen. Ich persönlich mag keine Programme,
welche ungefragt irgendwas ummodeln

ich habe das absichtlich so eingestellt, weil ich es in allen Dateien, die ich sonst so bearbeite (HTML, , Perl, Apache-Konfigurationen etc.), haben will - ich mag weder dort rechtsstehende Leerzeichen noch Tabulatoren.
Eines der Programme hier im Büro verlangt allerdings in seinen Klartext-Konfigurationsdateien TABs als logische Spaltentrenner ... :-(

Ich meinte ja nur, daß es theoretisch die
Möglichkeit gibt, daß jemand auch einen TAB
in den URL unterbringt. Ich habs mal mit TELNET
probiert, und es ging.

Das habe ich mir fast gedacht.
(Ich hätte es mit LWP::Simple versucht.)

Aber das abdecken zu wollen steht IMHO in keiner
sinnvollen Kosten/Nutzen-Relation. Irgendwann
sollte da Schluß sein.

Absolute Zustimmung - und vielen Dank für Deine Tips.
(Bisher habe ich mit den von mir angefangenen Threads ja fast nie irgendwelche Erfolge erzielt - der hier hat mir wirklich etwas gebracht.)

Viele Grüße
      Michael

[Achim Schrepfer]

Hi,

Absolute Zustimmung - und vielen Dank für Deine Tips.
(Bisher habe ich mit den von mir angefangenen Threads ja fast nie irgendwelche Erfolge erzielt - der hier hat mir wirklich etwas gebracht.)

vielleicht liegt das an Deinen recht komplex formulierten Fragestellungen ;-)
War übrigens auch einer der wenigen Threads, die ich von vorne bis hinten durchgelesen habe. Sehr interessante Diskussion.

Viele Grüsse,
Achim

[Klaus Mock]

Hallo,

Das einzige Trennzeichen, daß mir einfällt, daß weder im URL noch im Useragent vorkommen kann, ist das \n.
Warum also nicht den Log so aufbereiten, daß \n das 'Spaltentrennzeichen' ist und \n\n das 'Zeilentrennzeichen'?
Durch Änderung des INPUT_RECORD_SEPARATOR könntest Du dann auch wieder 'zeilenweise' einlesen.

Grüße
  Klaus

[Michael Schröpl]

Hi Klaus,

Das einzige Trennzeichen, daß mir einfällt, daß weder im URL noch im Useragent vorkommen kann, ist das \n.

Au ja - weil er das Trennzeichen von HTTP-Headern ist, richtig.

Warum also nicht den Log so aufbereiten, daß \n das
'Spaltentrennzeichen' ist und \n\n das 'Zeilentrennzeichen'?
Durch Änderung des INPUT_RECORD_SEPARATOR könntest Du dann
auch wieder 'zeilenweise' einlesen.

Das ist auf jeden Fall eine Idee, die ich mir durch den Kopf gehen lassen werde - auch wenn mir die Idee, eine logische auf mehrere physikalische Zeilen zu verteilen, nicht so spontan gefällt. (Für andere Benutzer sähe das dann doch sehr verwirrend aus.)

Inzwischen habe ich allerdings ein anderes Zeichen mit einer besonderen Eigenschaft gefunden, nämlich das '#'. Ein Browser sollte dieses Zeichen _eigentlich_ niemals als Bestandteil eines URL senden, weil es für ihn eine definierte, andere Bedeutung hat (die Abtrannung eines dokument-lokalen Ankers vom Dokument-URL). Kann jemand diese Idee widerlegen? (Hoffentlich nicht ... ;-)

Und wenn ich den URL zuverlässig parsen kann, dann ist mein Problem ja gelöst - _ein_ unbekanntes Feld (den UserAgent) halte ich aus.

Viele Grüße
      Michael

[Klaus Mock]

Hallo,

Das ist auf jeden Fall eine Idee, die ich mir durch den Kopf gehen lassen werde - auch wenn mir die Idee, eine logische auf mehrere physikalische Zeilen zu verteilen, nicht so spontan gefällt. (Für andere Benutzer sähe das dann doch sehr verwirrend aus.)

Du könntest das dann ja auch schön formatieren;-)
----Anfang Request ------------------------------
Remote-Host: 127.0.0.1
Username: -
Datum: [24/Feb/2002:17:40:27 +0100]
Request-Line: GET / HTTP/1.1
ResponseStatus: 200
Documente-Length: 2335
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:0.9.8) Gecko/20020204
----Ende Request ---------------------------------

Braucht zwar massig Platz, ist aber von jedem DAU noch zu lesen *g*.

Inzwischen habe ich allerdings ein anderes Zeichen mit einer besonderen Eigenschaft gefunden, nämlich das '#'. Ein Browser sollte dieses Zeichen _eigentlich_ niemals als Bestandteil eines URL senden, weil es für ihn eine definierte, andere Bedeutung hat (die Abtrannung eines dokument-lokalen Ankers vom Dokument-URL). Kann jemand diese Idee widerlegen? (Hoffentlich nicht ... ;-)

Hmm, habs gerade lokal ausprobiert, und bei mir stehts drin (Apache 1.3.22 über Mozill 0.9.8), wenn auch nur im Referer, aber einmal ist in dem Fall sicherlich nicht keinmal:-(

Und wenn ich den URL zuverlässig parsen kann, dann ist mein Problem ja gelöst - _ein_ unbekanntes Feld (den UserAgent) halte ich aus.

Andererseits, wenn Du %r verwendest dann ist der URL auch eindeutig zwischen %m und %H eingeschlossen, womit das eigentlich immer klar sein müßte.

Grüße
  Klaus

[Michael Schröpl]

Hi Klaus,

Du könntest das dann ja auch schön formatieren;-)

oh - das sieht wirklich hübsch aus.

Allerdings will ich das Ding für Server mit hohem Traffic einsetzen können, und da sollte das access_log nicht signifikant größer werden als auch sonst schon.

Inzwischen habe ich allerdings ein anderes Zeichen mit einer besonderen Eigenschaft gefunden, nämlich das '#'.
Hmm, habs gerade lokal ausprobiert, und bei mir stehts drin (Apache 1.3.22 über Mozill 0.9.8), wenn auch nur im Referer.

Ich meinte wirklich nur im URL - der Referrer ist keines meiner acht Felder. (Außer %r und dem UserAgent habe ich nur 'unkomplizierte' Felder drin, überwiegend reine Integers, aber u. a. auch den MIME-Typ.)

Andererseits, wenn Du %r verwendest

Ja, tue ich (weil ich nichts 'Feineres' gefunden habe. ich brauche sowohl den URL als auch die HTTP-Version; die Methode könnte ich derzeit entbehren, obwohl sich das ggf. noch ändern könnte).

dann ist der URL auch eindeutig zwischen %m und %H eingeschlossen, womit das eigentlich immer klar sein müßte.

Eben nicht!
Man kann sehr wohl "GET / HTTP/1.1" als Bestandteil sowohl des URL als auch des UserAgent senden, weil der URL innerhalb des access_log sowohl Leerzeichen als auch Gänsebeine enthalten kann.

Viele Grüße
      Michael