POST, GET eller REQUEST?

du bør bruge så specifik mulighed som muligt - request søger alle muligheder (post, get querystring...) igennem mens post og get kun ser specifikt på henholdsvis post og get.

men hvad er post og get? Hvornår skal man bruge hvad ?

det kommer an på hvordan du har submitted dine data - altså method="xx" i din form. get er adresse-linje - post er "skjult".

<ole>

Ved POST sendes data som datapakker, hvilket er en smule vanskeligere at få fat i. Ved GET sendes de som en querystreng i URL'en.

GET forespørgsler kan indeholde en ret begrænset mængde data (2-3KB alt efter browser), mens du med POST kan sende dramatisk meget mere.

Som jeg husker den historiske forklaring, var GET oprindelig tænkt som en egentlig forespørgsel ... altså til brug når man hentede data. POST var tænkt til at sende data til serveren med. Som på så mange andre punkter har nettet og forudsætningerne ændret sig, så man i dag ikke på den måde skelner mellem brugen.

Under alle omstændigheder er det altid godt at have styr på, hvor ens data/variabler præcist kommer fra. Derfor plejer rådet at lyde: Brug POST og GET i stedet for REQUEST, når det er muligt.

Skulle Erik Jacobsen eller Arne V læse med i baggrunden, må I meget gerne blande Jer. Den historiske forklaring, er jeg som sagt ikke helt 110 på, holder vand  =)

/mvh
</bole>

Fordelen ved GET er at brugere kan skrive parametre direkte ind i url'en
- og dermed bookmarke kald til din funktion.

Google søgningen er af GET typen - du kan se parametrene i url'en.
- og linke direkte til specifikke søgninger fra dit site.

Bagdelen er, som Ole nævner, at der ikke er plads til forfærdeligt meget data.

I de fleste tilfælde er POST metoden bedst (ingen technobabble i brugerens adresselinje)

Men de to metoder kan faktisk godt kombineres:

<form method="post" action="/find.php?svar=straks">
<input type="text" name="query">

Ovenstående vil sende parameteren svar til $_GET['svar'] og parameteren query til $_POST['query']

Ja, det kan lade sig gøre at kombinere POST og GET, men det betyder langt fra, det er en god idé  =)

Fremgangsmåden ses ikke sjældent i amatørkode, mens professionelle sætter rigtig meget ind på at minimere fejlmuligheder. Det kan man bl.a. gøre ved at sikre sig, man altid ved helt præcist, hvor data/variabler kommer fra - og derfor blander man ikke POST og GET data i én og samme forespørgsel

Smid Svar allesammen!

svar

Der er mindst 4 ting som skal vurderes i forhold til GET vs POST

HTTP standarden
---------------

HTTP standarden (RFC 2616) er meget klar:

GET skal vaere baade safe og idempotent

POST skal ikke vaere hverken safe eller idempotent

safe = paavirker ikke resultat af senere requests

idempotent = effekten af 1 request og N requests (N>1) med samme indhold er den samme

Deraf foelger at:

en form submit som kun returnerer data (i praksis en soegning) er det lovligt at bruge baade GET og POST

en form submit som aendrer (indsaetter/opdaterer/sletter) data skal vaere POST

GET tillader caching men POST tillader ikke caching.

Sikkerhed
---------

Der er to sikkerheds problemer med GET requests:

* data kan ses i adressefelt i browser, i browser historik og i diverse log filer

* de er meget nemme at generere via f.eks. IMG tag

Derfor:

* maa GET aldrig bruges til sensitive data

* maa GET aldrig bruges til aendringer af data [samme konklusion som ovenfor]

HTML standarderne
-----------------

GET tillader kun application/x-www-form-urlencoded mens POST tillader baade application/x-www-form-urlencoded og multipart/form-data.

Derfor kan GET ikke bruges til file upload.


Diverse implementations restriktioner
-------------------------------------

Der kan vaere limit paa data size for GET.

IE begraenser til 2048 minus faktisk path.

CGI scripts begraenser til max. shell kommando laengde paa server platform.

Ovenstaaende maa kunne sammefattes til:

hvis det er en soege form og det er vigtigt at cache resultatet (client side, proxy servere, reverse proxy servere, application) saa brug GET ellers i alle andre tilfaelde brug POST for form submit

Jeg lukker om et par dage, så skynd jer at smide Svar ;-)

svar