Das deutsche Python-Forum

In PyLucid fasse ich einfach die POST/GET Daten zusammen in ein Dict, Was für einen Sinn oder Unsinn ist das?

Ich sehe da keinen Nachteil, nur den einen, wenn man eine Variable mit unterschiedlichen Werten einmal im POST und gleichzeitig in GET hat, aber das sollte man IMHO nicht machen...

Ansonsten hat man den Vorteil, das man einfacher die Daten abfragen kann.

Irgendwelche Sicherheitsbedenken, von wegen, das man die POST Daten nicht sehen/manipulieren kann, sehe ich nicht. Schließlich kann jeder halbwegs erfahrene Mensch die Daten einfach selber erzeugen, natürlich nicht die Otto-Normalos, die es evtl. noch nicht mal hinbekommen würden, mit der URL zu spielen...

(Und da wir in letzter Zeit so viele Umfragen hatten, mach ich gleich auch mal eine draus )

+1 für die Unterscheidung. Weil man da die Daten besser unter Kontrolle hat.

Dateien? Was haben Dateien damit zu tun?

Idee hinter GET und POST ist schlicht und ergreifend dass es unterschiedliche Arten und Weisen darstellt auf eine serverseitige URL zuzugreifen. Wie der Name POST schon ausdrückt ist letzteres dazu gedacht etwas auf den Server draufzutun, ersteres um etwas vom Server zu holen.

Dass beide _heutzutage_ dazu missbraucht werden um CGI-Daten an einen Server zu schicken (bei GET mit einem Aufsatz, bei POST mit einer bestimmten dafür festgelegten Encoding der POST-Daten) ist eigentlich eine Laune der Geschichte.

REST (bitte mal auf Wikipedia gucken) macht diese Unterscheidung, und zwar ist dort zum Beispiel gesagt dass eine URL unterschiedlich reagieren kann, je nachdem ob ich zu Ihr Poste oder ob ich sie gette. So kann man sich zum Beispiel eine Wiki-URL vorstellen, die mittels GET abgerufen wird, während mittels POST halt die Seite neu gesetzt wird. Und das unabhängig von dem Parametern, die eigentlich nicht dazu gedacht sind um zu bestimmen was gemacht wird.

Ich persönlich gebe zu dass ich auch meißtens GET und POST in Webapps von mir verschwimmen lasse. Nur: eigentlich sollte man die Möglichkeit haben getrennt auf sie zuzugreifen, um eben REST anbieten zu können, und wie gesagt, es macht durchaus Sinn mehrere Methoden zu haben um auf eine URL zuzugreifen, um unterschiedliche Dinge auszudrücken die man mit der URL machen will.

--- Heiko.

Also ich bin für die Unterscheidung, weil:

1.) vermeide ich so ziemlich sicher die Überschneidung aus verschiedenen Scopes durch Namensgleichheit. Sollte zwar nicht vorkommen, kann aber und kann auch ziemlich mühselig sein so einen Fehler zu finden

2.) weis ich immer woher die Daten kommen. Wenn ich eine Variable aus dem POST erwarte und bekomme sie plötzlich dann doch aus dem GET, dann stimmt irgendwas nicht und ich nehm sie lieber nicht.

Also mir geht es generell nur um die Abfrage... Das man bestimmte Daten besser als GET und andere besser als POST sendet, ist mir schon klar... Man sollte z.B. immer die URL gefahrlos bookmarken können, d.h. es sollte beim Aufruf nicht versehendlich eine Aktion ausgeführt werden, die Sinnlos ist.

Mir geht es nur Serverseitig um die Unterscheidung. d.h. soll mein CGI Skript einen Unterschied zwischen POST und GET machen?

N317V hat geschrieben:2.) weis ich immer woher die Daten kommen. Wenn ich eine Variable aus dem POST erwarte und bekomme sie plötzlich dann doch aus dem GET, dann stimmt irgendwas nicht und ich nehm sie lieber nicht.

OK, du gehörst zur vorsichtigen Fraktion
Scherz beiseite... Das ist interessant. Aber was für "Gefahren" können dabei wirklich entstehen???

jens hat geschrieben:Mir geht es nur Serverseitig um die Unterscheidung. d.h. soll mein CGI Skript einen Unterschied zwischen POST und GET machen?

Hi Jens!

Wenn mir auch nur ein einziger Grund für die Unterscheidung zwischen POST und GET einfallen würde............

Nein, mir ist nichts eingefallen.

Alle Fälle, die ich bis jetzt kenne, hätten das Programmieren der Anwendung nur komplizierter gemacht, ohne auch nur einen zusätzlichen Nutzen zu bringen.

lg
Gerold

jens hat geschrieben:Dateien? Was haben Dateien damit zu tun?

Daten nicht Dateien. Für mich ist da ein großer Unterschied zwischen URL und POST Dateien, weil nur zweiteres zum übermitteln gedacht war, bis man für CGI eben die Sache mit dem QUERY_STRING eingeführt hat.

Also ich mach das nun so:

• self.request.POST
  self.request.GET
  und
  self.request.CGIdata <-- Beide Daten zusammen