nicht angemeldet
Rolf B
TS
Felix Riesterer
Felix Riesterer
dedlfix
Rolf B
encoder
Rolf B
dedlfix
dedlfix
Rolf B
Rolf B
dedlfix
dedlfix
Tach,
ich bin blutiger Anfänger mit PHP und habe eine Frage die mir Google nicht eindeutig erklären konnte.
Wenn ich mit PHP $_GET Variablen in einem Script aufnehme kann ich das ganz einfach auswerten wenn ich genau weiß wie die Variable in der URL geschrieben wurde. z.B. $_GET['meinevar'] kommt in der Url meinscript.php?meinevar=1
Was mache ich aber wenn der User oder die externe Software die Variable versehentlich so schreibt: meinscript.php?meineVar=1 dann müsste die aufgenommene Variable doch so heißen $_GET['meineVar']
Gibt es eine Möglichkeit die Groß und Kleinschreibung für die Bezeichnung der $GET Variablen zu ignorieren?
Danke + Gruß Walter
Hallo Walter,
du könntest Dir mit array_change_key_case eine Kopie des $_GET Superglobal machen:
Tabellenkalk
Matthias Apsel
Der Martin$getVars = array_change_key_case($_GET, CASE_LOWER);
$meineVar = $_GET['meinevar']; // ist Blödsinn, danke an TOM
$meineVar = $getVars['meinevar']; // klappt jetzt immer
(Code nach Hinweis von Tom editiert)
Da Du Dich als Anfänger outest, hier noch der Hinweis auf die kontextgerechte Behandlung. Was Du vom User bekommst, ist stets mit größtem Misstrauen zu behandeln. Wenn Du $meineVar für eine Datenbankabfrage verwenden willst, verwende ein prepared statement oder verwende die entsprechende escape-Funktion des Datenbanktreibers.
Wenn Du den Inhalt von $meineVar (oder das, was in der Datenbank gespeichert war) wieder zum Browser senden willst, verwende htmlspecialchars(). Andernfalls werden Dir alle Zeichen, die für den jeweiligen Kontext Sonderzeichen sind, die DB-Abfrage oder die Browser-Ausgabe zerreißen. Bei böswilligem Inhalt auch die Datenbank oder den Computer des Browsers.
Eine Alternative zu array_change_key_case wäre auch noch das sequenzielle Durchlaufen von $_GET mit einer foreach-Schleife, aber ich denke, dass array_change_key_case eleganter und schneller ist. Du musst es ja nur einmal aufrufen, auch wenn Du 47 Get-Parameter abholst...
Rolf
Hello,
Hallo Walter,
du könntest Dir mit array_change_key_case eine Kopie des $_GET Superglobal machen:
$getVars = array_change_key_case($_GET, CASE_LOWER); $meineVar = $_GET['meinevar']; // klappt jetzt immer
Du meintest bestimmt:
$meineVar = $getVars['meinevar'];
Das originale $_GET-Array hast Du doch nicht verändert.
Und unnötiges Umkopieren in Einzelvariablen (Skalare) ist iBäh!
Glück Auf
Tom vom Berg
Hallo TS,
oops, sorry.
Ja, umkopieren ist grundsätzlich erstmal Bäh, aber wenn man case-insensitive auf $_GET zugreifen will, muss man entweder umkopieren oder ein foreach laufen lassen. Warum ich umkopieren bevorzuge:
Rolf
Hello Rolf,
Ja, umkopieren ist grundsätzlich erstmal Bäh,
Du hast auch gelesen, dass ich "Umkopieren [von Arrayelementen] in Skalare" geschrieben bzw. gemeint habe?
In deinem Beispiel ist das vorherige komplette Kopieren des Arrays in ein "Arbeits-Array" durchaus angemessen. Andere Module des Systems benötigen ja vielleicht noch die Originaldaten.
Grundsätzlich sollte man Dedlfixs Einwand aber berücksichtigen, und gar keine Varianzen zulassen. Das reißt nur Löcher in die Sicherheitsstrategien, sollte man welche haben ;-)
Und den speziellen Anwendungsfall des OP kennen wir noch nicht, und ob es dafür keine bessere Lösung gibt.
Glück Auf
Tom vom Berg
Lieber Rolf,
eine Kopie des $_GET Superglobal machen:
wozu? strtolower($key) existiert.
Liebe Grüße
Felix Riesterer
Lieber Walter,
z.B. $_GET['meinevar'] meinscript.php?meineVar=1
foreach ($_GET as $key => $value) {
if (strtolower($key) == 'meinevar') {
// meinevar/meineVar/mEiNeVaR
do_something($value);
}
}
Liebe Grüße
Felix Riesterer
Tach!
Gibt es eine Möglichkeit die Groß und Kleinschreibung für die Bezeichnung der $GET Variablen zu ignorieren?
Ich würde versuchen, mich nicht darauf einzulassen. Gibt es einen Grund, warum ein User oder eine externe Software sich nicht an deine Vorgaben hält und eine andere Schreibweise verwendet? Oder anders gefragt, ist es notwendig, die falschen Schreibweisen zu berücksichtigen? Ist es zu viel Aufwand, die andere Software so zu ändern, dass sie richtige Requests erzeugt? Dem nächsten gefällt vielleicht die Schreibweise mit dem Binnenmajuskel nicht und schickt dir lieber einen Bindestrich zwischen den Wörtern. Oder er schreibt den Parameternamen auf irgeneine beliebige andere Weise anders. Abweichende Groß- oder Kleinschreibung lässt sich mit der von Rolf genannten Funktion ja noch sehr einfach korrigieren. Aber irgendwann wird dein Korrekturaufwand größer als der Nutzen. Versuch mal lieber, ob du deine Anwender nicht zur Verwendung der richtigen Schreibweise bewegen kannst.
dedlfix.
Hallo dedlfix,
dachte ich zuerst auch. Aber ich hatte auch ein bisschen in SO geschmökert, bevor ich antwortete. Da gab es zum einen den Hinweis auf eine Schreibweisenänderung, bei der man rückwärtskompatibel bleinen wollte, und dann beschrieb jemand den Fall, wo die URL beim Seitenaufruf vom Betriebssystem vermatscht wurde.
https://stackoverflow.com/questions/4211420/php-case-insensitive-parameters
Rolf
(steht inzwischen schon ähnlich da, ich lass es trotzdem mal stehen)
Das ist zwar nicht was du hören willst, aber eine andere Sichtweise wäre diese:
wenn der User oder die externe Software die Variable versehentlich so schreibt
... dann hat sie oder er die Variable falsch geschrieben und es ist sowohl in Ordnung als auch nachvollziehbar wenn dein Programm nicht funktioniert.
Mit solchen Versuchen zur Fehlerkorrektur machst du dir nur das Leben schwer.
Ich würde bekanntgeben "genau so wird das geschrieben, dann funktioniert es". Fertig.
Gibt es eine Möglichkeit die Groß und Kleinschreibung für die Bezeichnung der $GET Variablen zu ignorieren?
Wozu soll das gut sein? Gerade GET Parameter sind URL-Bestandteile die sehr leicht zu manipulieren sind. Also Benutzereingaben und gerade die sollten einer umfangreichen Prüfung standhalten. Wozu selbstverständlich auch die richtige Schreibweise gehört. Insbesondere dann wenn es sich um Schlüsselparameter handelt: Die legt nämlich der Programmierer fest, nicht der Anwender.
MFG
Hallo zusammen, vielen Dank für die vielen Antworten und die interessante Diskusion. array_change_key_case ist genau was ich gesucht habe. @dedlfix: In meinem Fall ist es tatsächlich so das unterschiedliche Produkte die Variablen unterschiedlich aufrufen können. Die API ist hier nur auf die Namen festgeschrieben, nicht auf die Groß und Kleinschreibung, liegt wohl daran das es aus alter Zeit stammt (ein CGI Programm, wo die Schreibweise egal war) Gruß Walter
Hallo zusammen, vielen Dank für die vielen Antworten und die interessante Diskusion. array_change_key_case ist genau was ich gesucht habe. @dedlfix: In meinem Fall ist es tatsächlich so das unterschiedliche Produkte die Variablen unterschiedlich aufrufen können. Die API ist hier nur auf die Namen festgeschrieben, nicht auf die Groß und Kleinschreibung, liegt wohl daran das es aus alter Zeit stammt (ein CGI Programm, wo die Schreibweise egal war) Gruß Walter
HTTP Parameter waren noch nie caseinsensitive. Ganz im Gegenteil, die zur CGI/1.1 Spezifikation gehörigen Enctypes application/x-www-form-urlencoded und multipart/form-data sind strict byteorientiert und das waren die shcon immer.
MFG
Hallo Email,
du hast sicher recht, aber wenn er nun mal früher ein CGI hatte, das großzügig war und die Namen case-insensitive abgefragt hat, dann sitzt er jetzt auf der Legacy und braucht er einen Workaround.
Wenn ein Schwarm unkoordinierter Clients in der Welt ist, kann man die kaum noch einfangen - es sei denn, man betreibt learning by failing und fragt von heute auf morgen strikt auf die Schreibweise ab, die in der Doku steht (sofern es eine gibt und sofern dort die Schreibweise konsistent ist). Denjenigen, die dann auf die Nase fallen, erklärt man, dass sie sich doch gefälligst ans Handbuch zu halten hätten.
Wäre Walter Oracle oder Microsoft, hätte er das ohne Skrupel getan.
Rolf
aber wenn er nun mal früher ein CGI hatte, das großzügig war und die Namen case-insensitive abgefragt hat, dann sitzt er jetzt auf der Legacy und braucht er einen Workaround.
Das hätte ich gerne mal gewusst wo dieser Blödsinn herkommt. Und nein einen Workaround gibt es nicht. MFG
Hallo,
Das hätte ich gerne mal gewusst wo dieser Blödsinn herkommt. Und nein einen Workaround gibt es nicht. MFG
Da hätte ich gerne mal gewusst wo dieser Blödsinn herkommt, dass du meinst, einen Workaround gäbe es nicht.
Gruß
Kalk
Du kannst Dir gerne weitere Enctypes ausdenken. Hast Du das schonmal gemacht? Gründe dafür gibt es. Aber es gab noch nie einen Grund, Parameter caseintensitive zu machen, das sehe ich nicht einmal als Workaround sondern einfach nur als Pfusch. MFG
Hallo Email,
einfach nur Pfusch.
Ob das damals, als es erstmalig gebaut wurde, Pfusch war oder eine eklige Notwendigkeit, können wir durch unser kleines Guckloch in die Vergangenheit schlecht beurteilen.
Aber egal was der Grund war, das „Feature“ ist nun vorhanden und wird von Clients verwendet. Deshalb ist es schwer weg zu bekommen. Je nach dem, wie wichtig die Verfügbarkeit dieses Dienstes ist, kann man sich für Pragmatismus (=case insensitivity übernehmen) oder Radikalität (strikt eingehaltene Schnittstelle und Absturz der Clients, die sich nicht dran halten) entscheiden.
Rolf
einfach nur Pfusch.
Ob das damals, als es erstmalig gebaut wurde, Pfusch war oder eine eklige Notwendigkeit, können wir durch unser kleines Guckloch in die Vergangenheit schlecht beurteilen.
Das kannst Du beurteilen wie Du möchtest. Aus meiner Sicht ist es Pfusch, weil die Geschäftslogik über Schlüsselparameter abgebildet wird und damit im Code festgeschrieben ist. An dieser Stelle caseinsensitiv zu arbeiten ist gober Unfug. MFG
Hallo Email,
einfach nur Pfusch.
Ob das damals, als es erstmalig gebaut wurde, Pfusch war oder eine eklige Notwendigkeit, können wir durch unser kleines Guckloch in die Vergangenheit schlecht beurteilen.
Das kannst Du beurteilen wie Du möchtest. Aus meiner Sicht ist es Pfusch, weil die Geschäftslogik über Schlüsselparameter abgebildet wird und damit im Code festgeschrieben ist. An dieser Stelle caseinsensitiv zu arbeiten ist gober Unfug. MFG
Inwiefern bildest du die Geschäftslogik in Parametern ab, wenn du Parameter Case-Insensitive machst?
Dein Argument ist nicht schlüssig.
LG,
CK
Inwiefern bildest du die Geschäftslogik in Parametern ab, wenn du Parameter Case-Insensitive machst?
Die Frage ergibt keinen Sinn. Die Geschäftslogik wird über Schlüsselparameter abgebildet und die legt der Programmierer fest. Und zwar casesensitive, MFG
Hallo Email,
Inwiefern bildest du die Geschäftslogik in Parametern ab, wenn du Parameter Case-Insensitive machst?
Die Frage ergibt keinen Sinn.
Das mag daran liegen, dass deine Argumentation keinen Sinn ergibt.
Die Geschäftslogik wird über Schlüsselparameter abgebildet und die legt der Programmierer fest. Und zwar casesensitive, MFG
Warum sollte es einen Unterschied machen, ob ich Parameter Case-Sensitive betrachte oder nicht? Warum sollte das eine „die Geschäftslogik über Schlüsselparameter abbilden“ (deine Wortwahl), aber das andere nicht?
Deine Argumentation ist nicht schlüssig.
LG,
CK
Warum sollte es einen Unterschied machen, ob ich Parameter Case-Sensitive betrachte oder nicht?
Darum:
if( $self->param('edit') ){}
elsif( $self->param('show') ){}
else{ die "Unbekannter Parameter\n" }
Schlüsselparameter, fest codiert.
Tach!
Warum sollte es einen Unterschied machen, ob ich Parameter Case-Sensitive betrachte oder nicht?
Darum:
if( $self->param('edit') ){} elsif( $self->param('show') ){} else{ die "Unbekannter Parameter\n" }Schlüsselparameter, fest codiert.
Das ist dein Problem, wenn du das so tust, und keine allgmeine Gesetzmäßigkeit, so wie du das darzustellen versuchst.
dedlfix.
Tach!
Warum sollte es einen Unterschied machen, ob ich Parameter Case-Sensitive betrachte oder nicht?
Darum:
if( $self->param('edit') ){} elsif( $self->param('show') ){} else{ die "Unbekannter Parameter\n" }Schlüsselparameter, fest codiert.
Das ist dein Problem, wenn du das so tust, und keine allgmeine Gesetzmäßigkeit, so wie du das darzustellen versuchst.
Wie willst Du denn sonst die Logik über HTTP schleifen wenn nicht über Parameter?
Da bin ich mal gespannt auf Deine Antwort. MFG
Tach!
Wie willst Du denn sonst die Logik über HTTP schleifen wenn nicht über Parameter?
Da bin ich mal gespannt auf Deine Antwort.
Deine Betrachtungsweise mit den von dir so genannten Schlüsselparametern ist nicht die einzige. Die Art und Weise, wie man aus der URL den auszuführenden Programmteil bestimmt, steht und fällt jedenfalls nicht mit der Schreibweise. Ansonsten kannst du dir gern meine beiden hauptsächlich verwendeten Frameworks anschauen, wie das dort gelöst ist: ASP.NET MVC und Angular. Die von dir gewünschten Teile befinden sich unter "Routing".
dedlfix.
Tach!
Wie willst Du denn sonst die Logik über HTTP schleifen wenn nicht über Parameter?
Da bin ich mal gespannt auf Deine Antwort.
Deine Betrachtungsweise mit den von dir so genannten Schlüsselparametern ist nicht die einzige. Die Art und Weise, wie man aus der URL den auszuführenden Programmteil bestimmt, steht und fällt jedenfalls nicht mit der Schreibweise.
Sauberer Code und insbesondere Teamarbeit steht und fällt mit der Schreibweise. Sogar mit der Einrückung. Wenn jeder Kollege die Parameter anders schreibt, ist das ein Chaos. Dass man es machen kann ist hier nicht die Frage. Und auch nicht das Wie.
MFG
Hallo Email,
Sauberer Code und insbesondere Teamarbeit steht und fällt mit der Schreibweise. Sogar mit der Einrückung.
Ja. Ja! Jaa! - kein Zweifel daran.
Einheitliche Schreibweise der URL-Parameter ist good practice, niemand widerspricht Dir darin.
Wenn jeder Kollege die Parameter anders schreibt, ist das ein Chaos.
Auch darin nicht.
Wir widersprechen Dir zum einen darin, dass das Business Logik ist. Nein, es ist technische Infrastruktur.
Ich widerspreche Dir zum anderen darin, dass es für den OP der beste Weg ist, diese good practice unverzüglich zu implementieren. Das Legacy-Chaos ist beim OP bereits eingetreten. Er hat einen Schwarm divergierender Clients. Niemand weiß, wieviel Aufwand eine Sanierung bedeutet. Wäre sie gut möglich, hätte der OP vermutlich nicht gefragt.
Rolf
Hallo Email,
Warum sollte es einen Unterschied machen, ob ich Parameter Case-Sensitive betrachte oder nicht?
Darum:
if( $self->param('edit') ){} elsif( $self->param('show') ){} else{ die "Unbekannter Parameter\n" }Schlüsselparameter, fest codiert.
Implementierungsdetail.
sub param {
my $key = shift;
return %data{lc $key};
}
LG,
CK
Hallo Christian,
du verstehst das nicht. Es ist in seinem Framework so drin und darum unbedingt richtig so.
Und er hat ja auch nicht völlig unrecht. Die einschlägigen RfCs (z.B. https://tools.ietf.org/html/rfc3986#section-6.2.3) sagen klar, dass man nur Schema und Host normalisieren muss und den Rest nicht sollte. Meint: Schema und Host sind case-insensitive gedacht, und der Rest ist per Default case-sensitive gedacht.
Wie Mike Kagansky (dessen Qualifikation ich nicht einordnen kann) hier vor 3 Jahren schrieb, gelten die entsprechenden RfCs für die Clients, nicht für die Server, und er schließt daraus, dass ein Client keine Annahmen treffen darf, wie ein Server seine URIs interpretiert. Der Server ist dagegen frei darin, in seiner Interpretation großzügig zu sein. Das entspricht auch generell der Internet-Philosophie: Sei strikt in dem, was Du erzeugst, und großzügig in dem, was Du verstehst.
Insofern ist ein Server, der Query-Parameter case-insensitive prüft, im Recht. Er muss es nicht tun, aber er darf es. Die Clients dürfen allerdings nicht davon ausgehen, dass er das tut. Wenn sie es tun, gehen sie kaputt, sobald jemand den Server austauscht.
Und das ist hier der Punkt. Das alte CGI des OP war case-insensitive und hatte Clients, die mit unterschiedlicher Schreibung unterwegs sind. Der OP hat den Wunsch, diese Clients nicht abzuschießen und möchte darum weiter case-insensitive bleiben. Dazu ist er nicht verpflichtet, aber kein RfC verbietet es. Also darf er es tun.
Rolf
Hallo Rolf,
du verstehst das nicht. Es ist in seinem Framework so drin und darum unbedingt richtig so.
Schon klar. Genau diese Denke wollte ich ja in Frage stellen.
Und er hat ja auch nicht völlig unrecht. Die einschlägigen RfCs (z.B. https://tools.ietf.org/html/rfc3986#section-6.2.3) sagen klar, dass man nur Schema und Host normalisieren muss und den Rest nicht sollte. Meint: Schema und Host sind case-insensitive gedacht, und der Rest ist per Default case-sensitive gedacht.
Wenn du den folgenden Absatz nicht ergänzt hättest, hätte ich dir hier vehement widersprechen müssen 😉
Wie Mike Kagansky (dessen Qualifikation ich nicht einordnen kann) hier vor 3 Jahren schrieb, gelten die entsprechenden RfCs für die Clients, nicht für die Server, und er schließt daraus, dass ein Client keine Annahmen treffen darf, wie ein Server seine URIs interpretiert. Der Server ist dagegen frei darin, in seiner Interpretation großzügig zu sein. Das entspricht auch generell der Internet-Philosophie: Sei strikt in dem, was Du erzeugst, und großzügig in dem, was Du verstehst.
Ja. Aber mir ging es in dem Fall gar nicht um den Standard (wobei ich die Auslegung von Mike Kagansky teile), sondern um die Aussage „case-sensitive bildet die Geschäftslogik ab, case-insensitive tut das nicht.“ Denn mir will tatsächlich einfach nicht in den Kopf, warum das so sein sollte. Und auch, warum das „Pfusch“ sein sollte ist mir schleierhaft.
Ob man das schön findet, das ist eine andere Frage. Ich persönlich empfinde es auch als hübscher, wenn man Parameter case-sensitive auswertet, aber das ist ein reines Geschmacksurteil und mir käme nicht in den Sinn, jemanden als Pfuscher zu bezeichnen, wenn er case-insensitive arbeitet.
LG,
CK
Hallo Christian,
dass das Auslesen von Parametern aus dem HTTP Request Geschäftslogik ist, würde ich auch bestreiten. Es ist technische Infrastruktur, wie auch das Routing des Requests zur passenden Implementierung.
Es kann Teil der Geschäftslogik sein, case-sensitive zu prüfen. Wenn die Geschäftslogik sich mit Schreibweisen beschäftigt. Ich meine jedoch, dass das in den meisten Fällen nicht der Fall ist und case-sensitivity in der Geschäftslogik irrelvant ist oder sogar stört.
Rolf
Hallo Rolf,
dass das Auslesen von Parametern aus dem HTTP Request Geschäftslogik ist, würde ich auch bestreiten. Es ist technische Infrastruktur, wie auch das Routing des Requests zur passenden Implementierung.
👍 ja, das denke ich auch. Aber das Fass wollte ich gar nicht erst aufmachen…
LG,
CK
es gab noch nie einen Grund, Parameter caseinsensitive zu machen
Vielleicht lief die ganze Chose mal auf einem IIS oder WAMPP und hat auf q=FooMatic reagiert indem eine Datei 'foomatic.txt', 'FOOMATIC.TXT' oder 'FooMatic.txt' geöffnet wurde. Was halt da war.
Lieber Rolf Rost,
es gab noch nie einen Grund, Parameter caseintensitive zu machen, das sehe ich nicht einmal als Workaround sondern einfach nur als Pfusch.
bist Du Dir sicher, dass alle Proxyserver damit keinen Pfusch machen?
Liebe Grüße
Felix Riesterer
Hallo Felix Riesterer,
bist Du Dir sicher, dass alle Proxyserver damit keinen Pfusch machen?
Bist du dir sicher, dass kein Proxiserver damit Pfusch macht? 😉
Bis demnächst
Matthias
Hallo zusammen, vielen Dank für die vielen Antworten und die interessante Diskusion. array_change_key_case ist genau was ich gesucht habe. @dedlfix: In meinem Fall ist es tatsächlich so das unterschiedliche Produkte die Variablen unterschiedlich aufrufen können. Die API ist hier nur auf die Namen festgeschrieben, nicht auf die Groß und Kleinschreibung, liegt wohl daran das es aus alter Zeit stammt (ein CGI Programm, wo die Schreibweise egal war) Gruß Walter
HTTP Parameter waren noch nie caseinsensitive. Ganz im Gegenteil, die zur CGI/1.1 Spezifikation gehörigen Enctypes application/x-www-form-urlencoded und multipart/form-data sind strict byteorientiert und das waren die shcon immer.
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, HTTP_ACCEPT, HTTP_COOKIES, HTTP_ACCEPT_LANGUAGE usw. wobei aus Bindestrichen Unterstriche werden. Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array wo Großkleinschreibung selbstverständlich gilt.
MFG
Tach!
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, [...] Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array [...]
Das stimmt so nicht. Nur eine ausgewählte Menge an Request-Headern ist in CGI spezifiziert. Auch landet der Rest unter PHP nicht in $_SERVER.
ist das ein Array wo Großkleinschreibung selbstverständlich gilt.
Das gilt in PHP für jedes Array. Und man kann array_change_key_case() auch auf dieses Array anwenden, wenn man mag. Das ist also auch kein Argument, zwingend eine bestimmte Schreibweise einhalten zu müssen.
dedlfix.
Tach!
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, [...] Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array [...]
Das stimmt so nicht. Nur eine ausgewählte Menge an Request-Headern ist in CGI spezifiziert.
Serverkonfiguration! Ich hatte schon Server die zeigten das Passwort eines REMOTE_USER in Klartext -- Mit Sicherheit kein Standard.
MFG
Tach!
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, [...] Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array [...]
Das stimmt so nicht. Nur eine ausgewählte Menge an Request-Headern ist in CGI spezifiziert.
Serverkonfiguration!
Deine hingeworfenen Stichwörter machen für mich nicht verständlich, was du auszudrücken versuchst. Die Serverkonfiguration legt fest, was im CGI-Standard definiert ist?
Aber selbst wenn die Serverkonfiguration festlegt, was (unabhängig von der Erwähnung im CGI-Standard) via CGI oder anderen Schnittstellen zum Programm durchgereicht wird, stimmt die Aussage nicht. Um alle Header zu bekommen, unabhängig von dem, was PHP aus CGI oder anderen Quellen zuzüglich eigener Ergänzungen im Array $_SERVER auswählt, muss man apache_request_headers() nehmen, um an alle Header zu kommen.
dedlfix.
Tach!
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, [...] Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array [...]
Das stimmt so nicht. Nur eine ausgewählte Menge an Request-Headern ist in CGI spezifiziert.
Serverkonfiguration!
Deine hingeworfenen Stichwörter machen für mich nicht verständlich, was du auszudrücken versuchst. Die Serverkonfiguration legt fest, was im CGI-Standard definiert ist?
Die Serverkonfiguration ist eine Duchführungsbestimmung zur Umsetzung von Standards.
MFG
Hallo Emaipl,
Ergänzung: RfC2616 legt fest, dass Header-Namen ein token und case-insensitive sind. Token bedeutet ein bytecodiertes ASCII ZEichen aus dem Code-Intervall [33,126] abzüglich der folgenden Zeichen: ()<>[]{}@,;:=?/\ und doppeltes Anführungszeichen.
Deswegen darf der CGI-Standard definieren, dass sie für CGI-Anwendungen in Großschrift umgewandelt werden. Die Umwandlung von - in _ könnte problematisch sein, weil im RfC beide Zeichen grundsätzlich in dem Token, das den Headername bildet, erlaubt sind, ist es aber nicht, weil alle Headernamen nur das - verwenden.
Quelle: https://tools.ietf.org/html/rfc2616#section-4.2 - in 2014 durch 723x RfCs überlagert, aber da CGI älter ist, dürften diese grundsätzlichen Dinge noch gelten. Ich hatte jetzt keine Lust, einen Schwarm Update-RfCs zu studieren.
Rolf
Hallo Emaipl,
Ergänzung: RfC2616 legt fest, dass Header-Namen ein token und case-insensitive sind. Token bedeutet ein bytecodiertes ASCII ZEichen aus dem Code-Intervall [33,126] abzüglich der folgenden Zeichen: ()<>[]{}@,;:=?/\ und doppeltes Anführungszeichen.
Deswegen darf der CGI-Standard definieren, dass sie für CGI-Anwendungen in Großschrift umgewandelt werden. Die Umwandlung von - in _ könnte problematisch sein, weil im RfC beide Zeichen grundsätzlich in dem Token, das den Headername bildet, erlaubt sind, ist es aber nicht, weil alle Headernamen nur das - verwenden.
Quelle: https://tools.ietf.org/html/rfc2616#section-4.2 - in 2014 durch 723x RfCs überlagert, aber da CGI älter ist, dürften diese grundsätzlichen Dinge noch gelten. Ich hatte jetzt keine Lust, einen Schwarm Update-RfCs zu studieren.
Aber schön daß Du es hier ergänzt hast!
Und jetzt können wir mal darüber nachdenken was für einen Sinn es machen würde, wenn ein Client einen Customheader x-hr sendet, der Server das nach HTTP_X_HR umwandelt (das macht er sowieso) und ein Programmierer das unbedingt als X-hR sowie ein anderer Programmierer das als x_Hr abgefragt haben möchte.
MFG
Hallo Email,
der eine - der andere - x-Hr - X_Hr
Es ging um die Clients. Der eine schickt 'Content-Type', der andere 'content-type', der dritte vielleicht 'CONTENT_TYPE'. Weil Header case-insensitive sind, weiß jeder Programmierer, dass er das case-insensitive abfragen muss. CGI erleichert das durch Konvertierung in Großschrift und verzeiht durch Wandlung von - in _ auch noch einen weiteren Fehler.
Walter möchte auch Fehler verzeihen. Er hat undisziplizierte Clients, die userId, UserID oder userid als Query-Parameter schicken, und will deshalb die Query-Parameternamen ebenfalls case-insensitive prüfen.
Dahammas doch. CGI ist das Vorbild für Walters gewünschtes Vorgehen. War doch gar nicht so schwer, die Logik in seiner Idee zu entdecken 😜
Rolf
Eine Umwandlung ergibt einen logischen Sinn. Deswegen ja mein Hinweis auf den Standard bezüglich der Header wo diese eine Umwandlung standardmäßig stattfindet. Schließlich haben Anwender keinen bzw. nur begrenzten Einfluß darauf, welche Schreibweise ein Browser beim Senden der Requestheader verwendet. So findet sich die vom Anwender bevorzugte Sprache stets in HTTP_ACCEPT_LANGUAGE.
Parameter (Enctypes application/x-www-form-urlencoded und multipart/form-data) jedoch werden vom Browser nicht namentlich verändert. Die legt der Programmierer/Designer fest und so wie er die ins Programm bzw. HTML <input name="ort" /> schreibt, werden die auch gesendet.
MFG
Tach!
Eine Umwandlung ergibt einen logischen Sinn. Deswegen ja mein Hinweis auf den Standard bezüglich der Header wo diese eine Umwandlung standardmäßig stattfindet.
Der vorliegende Fall betraf den Querystring und nicht die HTTP-Header. Angenommen, dein "eine Umwandlung"-Argument ergäbe einen Sinn, dann ist diese eine Umwandlung der Aufruf der Funktion array_change_key_case(). Server und PHP haben ansonsten nichts am Querystrig geändert - abgesehen von der Zerlegung für $_GET.
Ansonsten ist es in meinen Augen im Prinzip völlig irrelevant, wie oft und welche Änderungen stattfinden, damit das Programm am Ende sein Ziel erreichen kann. Es ist lediglich Aufwand. Das Argument, möglichst keine alternativen Schreibweisen zuzulassen, dient vorwiegend dafür, diesen Aufwand kleinzuhalten.
dedlfix.
hi @Rolf B
Eine Umwandlung ergibt einen logischen Sinn. Deswegen ja mein Hinweis auf den Standard bezüglich der Header wo diese eine Umwandlung standardmäßig stattfindet. Schließlich haben Anwender keinen bzw. nur begrenzten Einfluß darauf, welche Schreibweise ein Browser beim Senden der Requestheader verwendet. So findet sich die vom Anwender bevorzugte Sprache stets in HTTP_ACCEPT_LANGUAGE.
Parameter (Enctypes application/x-www-form-urlencoded und multipart/form-data) jedoch werden vom Browser nicht namentlich verändert. Die legt der Programmierer/Designer fest und so wie er die ins Programm bzw. HTML
<input name="ort" />schreibt, werden die auch gesendet.
PS: Ich habe gerade eine etwas umfangreichere Klasse am Wickel, mein Forum. Als Kompaktklasse (ich nenne diese Bauform so) befinden sich Code (ca 300 Zeilen) und das HTML-Template (ca 100 Zeilen) in einer Datei, natürlich sauber voneinander getrennt.
Der Controller kontrolliert eine Handvoll Parameter: edit, update, rmthread, rmsub, show und putmesg. Wobei die ersten 4 an das intern konfigurierte admin-Attribut gebunden sind, z.B.:
elsif($self->param('edit') && $self->eav('admin')){}
Genau dieselben Parameter finden sich im HTML Template, was zusammen mit dem Code zur gleichen Zeit im Editor ist, wieder und damit im Browser. D.h., die Schreibweise ist natürlich auch dieselbe.
Selbst wenn ich jetzt einen Parser hätte der alle Parameter nach uppercase wandeln würde, wäre ist doch Unfug, als eine Person mit einem Editor in einundderselben Datei darauf bestehen zu wollen daß zur Parameterkontrolle die Schreibweise beliebig sein soll. Über diese Frage hat auch meine Frau nur mit dem Kopf geschüttelt.
MFG
Über diese Frage hat auch meine Frau nur mit dem Kopf geschüttelt.
Wenn Deine Frau über sonst nix den Kopf schüttelt: WIN!
Über diese Frage hat auch meine Frau nur mit dem Kopf geschüttelt.
Wenn Deine Frau über sonst nix den Kopf schüttelt: WIN!
Man kanns auch so formulieren: Wenn ein Team von Programmierern, sagen wir 10 Mitarbeiter, es nicht auf die Reihe kriegen, sich über die Schreibweise (Groß- Kleinschreibung) einer Handvoll Parameter zu einigen, ist das dann ein Thema für die Gewerkschaft oder ein Thema für den Betriebsrat?
😉
PS: Aber ich kann mir mittlerweile denken wo dieser Blödsinn herkommt. Nicht von einem alten CGI sondern von der Unsitte, Funktionen namentlich und Klassennamen über sogenannte Pseudoklassen auf URLs abzubilden.
Hallo,
ist das dann ein Thema für die Gewerkschaft oder ein Thema für den Betriebsrat?
Du musst die Frage deiner Frau anders stellen:
Hat die Gewerkschaft eigentlich einen Betriebsrat und wenn nein, dürfen Betriebsräte dann wenigstens Mitglied in der Gewerkschaft sein?
Gruß
Kalk
Hi,
Hat die Gewerkschaft eigentlich einen Betriebsrat und wenn nein, dürfen Betriebsräte dann wenigstens Mitglied in der Gewerkschaft sein?
vor einiger Zeit auf SWR3 gehört:
F: Dürfen Finanzbeamte eigentlich ihren Kaffee schwarz trinken?
A: Ja, aber sie dürfen die Tasse nicht absetzen.
Ciao,
Martin
Hi,
Hat die Gewerkschaft eigentlich einen Betriebsrat und wenn nein, dürfen Betriebsräte dann wenigstens Mitglied in der Gewerkschaft sein?
vor einiger Zeit auf SWR3 gehört:
F: Dürfen Finanzbeamte eigentlich ihren Kaffee schwarz trinken?
A: Ja, aber sie dürfen die Tasse nicht absetzen.
Beamter kommt mit blauem Auge nach Hause. Frau: Na, wieder aufm Stempelkissen eingeschlafen!?
Tach!
Ergänzung: Der CGI/1.1 Standard betrachtet Requestheader auch als Parameter. Diese werden allesamt in Großschreibung umgewandelt, HTTP_ACCEPT, HTTP_COOKIES, HTTP_ACCEPT_LANGUAGE usw. wobei aus Bindestrichen Unterstriche werden. Alle Header finden sich lt. CGI/1.1 in der Serverumgebung, in PHP ist das ein Array wo Großkleinschreibung selbstverständlich gilt.
Ein vorangestelltes HTTP_ ist der entscheidende Punkt, den du nicht erwähnt hast. Lediglich die Umwandlung in Großschreibung. Mit dem HTTP_ finden sich dann doch die Header in $_SERVER.
dedlfix.