Unterschied GET - POST

[Markus]

Hi Leute

Was ist generell der Unterschied zwischen GET und POST?

Welche Variante nimmt man, wenn man eine Datenbankabfrage macht?

Wie wirken sich die Unterschiede aus bei einer Datenbankabfrage?

Danke

MFG
Markus

[Frank aus Ulm]

Hi, hallo

was der Unterschied ist, wird im Archiv mindestens genauso gut beschrieben wie in SelfHTML selbst.

Du hast also eine der Forumsregeln nicht beachtet.

GET/POST haben nichts mit Datenbankabfragen zu tun.

GET/POST dienen u.a. umgangssprachlich erklärt dazu, daß man Parameter bzw Werte von einer Seite zu einer anderen Seite über der HTTP übergeben kann.

Erläutere bitte deine Frage nochmal. So wie sie jetzt ist, ergibt sie keinen Sinn.

Tschau, tschüß,
Frank

[Markus]

Hi Frank

Es wird von Suchformular auf eine Ausgabeseite übermittelt!

Dies kann ich per POST/GET machen.

Was bewirkt es aber?

bei get wird der ganze URL mitgeschickt mit den abfragefeldern..

was hat es sonst noch zu bedeuten?

MFG
Markus

[Frank aus Ulm]

Hi, hallo

technisch gesehen ist es zu einem gewissen Grad wurscht, womit du das machst, aber

der QueryString einer URL (-> GET Methode) hat eine Mengenbeschränkung > URL < 1024 Zeichen

das macht bei einer Suchabfrage, wie du sie dir vorstellst aber sicher nichts

und man sieht halt die übergebenen Werte in der URL der Zielseite (soweit nicht verschlüsselt)

POST sendet die Daten im HTTP Header mit

Zugriff auf GET gesendete Daten erfolgt unter ASP mit Request.QueryString(paramname) und bei POST mit Request.Form(paramname)  wobei der Paramname der Name des HTML-Input-Elementes ist -> <input type="text" name="dasistdername">

Wenn du den Wert auf der Folgeseite wieder gelesen hast, dann gibt es keinen Unterschied mehr in Bezug auf die Weiterverarbeitung.

Klärt das deine Frage?

Tschau, tschüß,
Frank

[Markus]

Merci Frank

Das war eine tolle Erklärung genau das wollte ich wissen!

Was ist wenn es über die 1024 Zeichen gehen sollte?

der QueryString einer URL (-> GET Methode) hat eine Mengenbeschränkung > URL < 1024 Zeichen

wie könnte man sowas verschlüsseln?

und man sieht halt die übergebenen Werte in der URL der Zielseite (soweit nicht verschlüsselt)

hab ich auf diesen Header irgendwie einen Zugriff?

POST sendet die Daten im HTTP Header mit

Wie schauts aus wenn man 2 Werte auslesen möchte zb.paramname und paramname1 ?
Request.QueryString(paramname & paramname1) oder wie?

Zugriff auf GET gesendete Daten erfolgt unter ASP mit Request.QueryString(paramname) und bei POST mit Request.Form(paramname)  wobei der Paramname der Name des HTML-Input-Elementes ist -> <input type="text" name="dasistdername">

Danke

MFG
Markus

[Frank aus Ulm]

oh oh ... :-)   Bitte besorg dir dringend ein Buch um die Gründzüge zu verstehen.

ich würde auf "abschneiden" tippen bei URL mit Länge(URL) > 1024 ??  Noch nie in die Versuchung gekommen, das zu probieren.

dir ist schon bewußt, was es unter ASP für Objekte gibt und wozu die dienen.

Request -> beinhaltet alle gesendeten Daten im Fall Browser ruft URL auf

Response -> übersetzt Antwort -> gibt Daten aus, die dann an den Browser gesendet werden als Antwort auf eine URL Anfrage (Request)

Verschlüsseln von URLs würde für deinen Kenntnisstand zu weit führen und ist für dieses Problem "out of scope"

beide Objekte haben verschiedene

Methods / Methoden
Properties / Eigenschaften
Collections / Auflistungen

Response.Write und Response.AddHeader sind Methoden des Response Objektes.

Request.Form ist die Auflistung, in der alle Parameterpaare enthalten sind, die per HTTP POST gesendet wurden

Request.QueryString analog für GET Daten

Auflistung bedeutet in dem Fall Key-Value Liste, wobei der Key der Parametername ist und der Value der Parameterwert:

x.asp?param1=wert1   -> request.QueryString("param1") = "wert1"

hast du mehrere Elemente per GET gesendet, hast du auch mehrere Elemente in der Auflistung ... jeweils identifiziert durch den parameternamen als KEY

Auf den HTTP Header, der an den Browser zusammen mit der HTML Ausgabe gesendet wird oder von dort kommt im Falle des Formularabschickens, hat man Zugriff:

Lesend über das Request Objekt, schreibend über das Response Objekt, wobei schreibend nicht unbedingt etwas für Anfänger ist und man auch nicht alles in den Header schreiben kann.

Tschau, tschüß,
Frank

[Cheatah]

Hi,

der QueryString einer URL (-> GET Methode) hat eine Mengenbeschränkung > URL < 1024 Zeichen

nein, nein, nein. Warum hält sich dieses Gerücht nur so hartnäckig, noch dazu in so unterschiedlichen Varianten?

Recherchiere bitte im Archiv, was (k)eine Beschränkung hat, warum dem so ist und wo sie liegt.

POST sendet die Daten im HTTP Header mit

Vertipper? Bei GET stehen die Parameter im HTTP-Header (nämlich in der Requestline), bei POST jedoch im Body des Requests. Für die Verarbeitung der Daten macht das, wie Du schon sagtest, i.d.R. keinen Unterschied; für den Versand sowie das Verhalten des Client in verschiedenen Punkten (z.B. Caching) jedoch schon.

Cheatah

[Frank aus Ulm]

Hi Cheatah

ooops, da bin ich wohl seit langem einem Irrglauben aufgesessen gewesen.

Danke für die Berichtigung. Für die Kuzunft bin ich wissender :-)

Tschau, tschüß,
Frank

[Cheatah]

Hi,

ooops, da bin ich wohl seit langem einem Irrglauben aufgesessen gewesen.

man sollte mal ein Buch schreiben: "Populäre Irrtümer im Webdesign" :-)

Cheatah

[norbert =:-)]

Hi,

und am Anfang würde stehen

"HTML programmieren" ;-)

Hat das schon mal einer im Forumsarchiv gesucht - sicher eine der häufisten Begriffskombinationen ...

mfg

norbert =:-)

[Cheatah]

Hi,

und am Anfang würde stehen
"HTML programmieren" ;-)

*g* auf Platz 1 der dünnsten Bücher der Welt steht IMHO der Titel "Die besten HTML-Programmierer" ;-)

Cheatah

[MudGuard]

Hi,

und am Anfang würde stehen
"HTML programmieren" ;-)

Und gleich danach:
Der Internet Explorer ist ein webtauglicher Browser ;-)

cu,
Andreas

[Frank aus Ulm]

Hi, hallo

Und gleich danach:
Der Internet Explorer ist ein webtauglicher Browser ;-)

hmm, das disqualifiziert dich automatisch, weil ! der IE HTML mit CSS definitiv anzeigen kann,

wenn nicht, dann könnte ich dir jetzt nicht schreiben, dass deine Aussage blödsinn ist, auch wenn mit einem ;-) versehen.

Tschau, tschüß,
Frank

[MudGuard]

Hi,

Der Internet Explorer ist ein webtauglicher Browser ;-)

hmm, das disqualifiziert dich automatisch, weil ! der IE HTML mit CSS definitiv anzeigen kann,

1. kann er vieles von CSS nicht anzeigen.
2. hatte ich absichtlich nicht geschrieben: Der Internet Explorer ist ein HTML- oder CSS-tauglicher Browser

wenn nicht, dann könnte ich dir jetzt nicht schreiben, dass deine Aussage blödsinn ist, auch wenn mit einem ;-) versehen.

Da Du die Aussage offensichtlich nicht gelesen hast, ignoriere ich das.

cu,
Andreas

[Frank aus Ulm]

Hi MudGuard

2. hatte ich absichtlich nicht geschrieben: Der Internet Explorer ist ein HTML- oder CSS-tauglicher Browser
   Da Du die Aussage offensichtlich nicht gelesen hast, ignoriere ich das.

deine Aussage folgte in einer Liste von "Irrglauben" bezüglich Internet.

Ich wiederhole mich jetzt, aber gerne:

Das gemeine Web auch Internet genannt besteht nun mal <added>abgesehen von downloadbaren Dateien</added> aus HTML (plus dem Zusatz CSS) und damit ist ein Programm ein Browser -> damit webtauglich wenn das Programm HTML und CSS darstellen kann.

Deine Pauschalisierung, der IE wäre ein webtauglicher Browser als Irrglauben darzustellen ist einfach falsch.

Hab ja nichts gegen die Aussage "IE ist schlecht, weil ... " aber Fakten umzudrehen entspricht nicht dem Niveau dieses Forums.

Tschau, tschüß,
Frank

[MudGuard]

Hi,

2. hatte ich absichtlich nicht geschrieben: Der Internet Explorer ist ein HTML- oder CSS-tauglicher Browser
   Da Du die Aussage offensichtlich nicht gelesen hast, ignoriere ich das.

Das gemeine Web auch Internet genannt besteht nun mal <added>abgesehen von downloadbaren Dateien</added> aus HTML (plus dem Zusatz CSS) und damit ist ein Programm ein Browser -> damit webtauglich wenn das Programm HTML und CSS darstellen kann.

Die Darstellung von Webseiten ist Grundvoraussetzung für ein webtaugliches Programm. Daß der IE (in gewissem Maße) dazu in der Lage ist, habe ich in diesem Thread nicht bestritten.
Aber wenn ein Programm so viele Sicherheitslücken aufweist, taugt es eben NICHT zur Benutzung im Web.

Hab ja nichts gegen die Aussage "IE ist schlecht, weil ... " aber Fakten umzudrehen entspricht nicht dem Niveau dieses Forums.

Wo bitte habe ICH Fakten verdreht?
DU hast mir eine Aussage unterstellt, die ich nie gemacht habe.

cu,
Andreas

[Cheatah]

Hi,

Der Internet Explorer ist ein webtauglicher Browser ;-)
hmm, das disqualifiziert dich automatisch, weil ! der IE HTML mit CSS definitiv anzeigen kann,

[ ] ein Browser definiert sich als HTML- und CSS-Anzeigegerät.

Cheatah

[Frank aus Ulm]

Hi, hallo

[ ] ein Browser definiert sich als HTML- und CSS-Anzeigegerät.

weiß nicht ???!!! ;-)

und da das gemeine Web aus HTML (plus dem Zusatz CSS) besteht und der IE in der Lage ist, beides anzuzeigen - über die standartkonformität wollten wir nicht reden, oder? - ergibt sich mit deiner Definition

IE = Browser = webtauglich

denn einen schönen Abend noch,

Frank

[Henryk Plötz]

Moin,

Der Internet Explorer ist ein webtauglicher Browser ;-)

hmm, das disqualifiziert dich automatisch, weil ! der IE HTML mit CSS definitiv anzeigen kann,

HTML- und CSS-Anzeigefähigkeit sind eine notwendige, aber keine hinreichenden Bedingung für Webtauglichkeit. HTTP-Unterstützung wäre eine weitere notwendige Bedingung, und da steht der IE sehr schlecht da: Er verstößt absichtlich gegen RFC 2616 in mindestens einem Punkt (bei der Content-Type-Auswertung) und seine Implementation von Digest Access Authententication ist in allen Versionen kaputt bis zur Unbrauchbarkeit. Schon alleine letzteres schließt ihn von der Webtauglichkeit aus.

[Rouven]

Hi,

der QueryString einer URL (-> GET Methode) hat eine Mengenbeschränkung > URL < 1024 Zeichen

nein, nein, nein. Warum hält sich dieses Gerücht nur so hartnäckig, noch dazu in so unterschiedlichen Varianten?

Nun ja, grundsätzlich hast du, auch nach RFC sicherlich Recht, allerdings:
http://www.jetools.com/content/resources/whitepapers/HTTP_GET_Requests.rtf:
Apache

The Apache web server applies a compile-time constant max request line limit.  As distributed, this limit is set to 8190 characters (including method and protocol).

As of apache 1.3.2 and later, there is a config parameter in httpd.conf that allows site administrators to lower this limit.  The limit cannot be raised, except at compile time.

[...]

Summary

It is worth mentioning that this document applies to limitations on the length of a URL.  The URL could be a GET or POST, however the restrictions are most commonly a factor in GET requests.

Based on the above information, the following recommendations are made based on the broad type of application under consideration.

Application Max URL Length Recommendation
Intranet Application Based on your lowest common denominator as defined in the above sections.  Value could be as high as 8190 or more if the most capable systems are used.
Web Application targeting 4 + level AOL, IE, and Netscape browsers, more capable users 2048
Web Application, targeting 3 + level AOL, IE, and Netscape browsers, most corporate proxy servers 1024
Web Application targeting widest possible audience, potential for obscure browsers, proxy servers, etc. 255

Also, remember the following mathematical certainty when performing your calculations:
2+2=5 for sufficiently large values of 2.

[Cheatah]

Hi,

Warum hält sich dieses Gerücht nur so hartnäckig, noch dazu in so unterschiedlichen Varianten?
Nun ja, grundsätzlich hast du, auch nach RFC sicherlich Recht, allerdings:

bitte kein "allerdings". Das steht alles schon im Archiv - und noch viel mehr.

Cheatah