---

Hej gruppe...

Jeg sidder og overvejer at bruger GET-metoden i stedet for POST da den er
betydeligt hurtigere. Men jeg kan godt forestille mig at den giver problemer
da alle data bliver skrevet oppe i stien til siden.

Er der nogle der har dårlige/gode erfaringer med dette??

----
Mvh Kasper
www.cszone.h4f.dk
www.levithan.h4f.dk

---

Personligt mener jeg at det kan være fuldstændig ligegyldig om folk kan se
hvilke variabler dit script benytter sig af.

De er pine død nød til at kunne få adgang til din server før de kan bruge
det til noget som helst konstruktivt, og hvis de har adgang til serveren kan
stien være ligegyldig. Du skal bare ikke smide rundt med password og
brugernavne, og hvis du gør det kan du jo bare smide en MD5() hen over den.

Der er så de estetiske spørgsmål tilbage, men det er vel en smagssag....jer
er personlig ligeglad...



Joe

"Kasper Johansen" <kajo08@ihnykf.dk> wrote in message
news:3dad266c$0$21988$edfadb0f@dspool01.news.tele.dk...

> Hej gruppe...
>
> Jeg sidder og overvejer at bruger GET-metoden i stedet for POST da den er
> betydeligt hurtigere. Men jeg kan godt forestille mig at den giver
problemer
> da alle data bliver skrevet oppe i stien til siden.
>
> Er der nogle der har dårlige/gode erfaringer med dette??
>
> ----
> Mvh Kasper
> www.cszone.h4f.dk
> www.levithan.h4f.dk
>
>

---

"Kasper Johansen" <kajo08@ihnykf.dk> wrote in message
news:3dad266c$0$21988$edfadb0f@dspool01.news.tele.dk...
> Hej gruppe...
>
> Jeg sidder og overvejer at bruger GET-metoden i stedet for POST da den er
> betydeligt hurtigere. Men jeg kan godt forestille mig at den giver
problemer
> da alle data bliver skrevet oppe i stien til siden.
>
> Er der nogle der har dårlige/gode erfaringer med dette??

Hvad mener du med at POST er langsommere? Det har jeg aldrig lagt mærke til?

Jeg har været ude for at hvis query-stringen bliver for lang (jeg ved ikke
hvor lang det er), kan den blive cuttet af et sted i systemet.

Mht sikkerhed -- joe var inde på at man kan se/ikke se variablene -- de er
(teoretisk set) lige så synlige i POST, og man skal (heller) ikke smide
rundt med brugernavn og/eller passwords i POST.


--
Venlig hilsen
Martin Seebach
- min email adresse virker..

---

Kasper Johansen wrote in <3dad266c$0$21988$edfadb0f@dspool01.news.tele.dk>:
> Jeg sidder og overvejer at bruger GET-metoden i stedet for POST da den er
> betydeligt hurtigere. Men jeg kan godt forestille mig at den giver
> problemer da alle data bliver skrevet oppe i stien til siden.

GET og POST har andre (og vigtigere) forskelle end om form-data er en del af
urlen.

Brug dem hver især til det, de er beregnet til. Eneste grund jeg kender til
at gøre andet, er hvis der er for meget data til GET.

Jeg har desværre ikke lige tid til at forklare forskellene ligenu. :-/

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen wrote in <Zddr9.113378$Qk5.4927063@news010.worldonline.dk>:
> GET og POST har andre (og vigtigere) forskelle end om form-data er en del
> af urlen.
[...]
> Jeg har desværre ikke lige tid til at forklare forskellene ligenu. :-/

Jeg har bedre tid nu, og kan se at ingen andre har fortalt det.

GET er til at HENTE data med, altså til at kigge passivt.
POST er til at SENDE data med, og til at "gøre noget".

GET bruges når man surfer helt almindeligt rundt. Så laver man jo ikke andet
end at modtage data. Hvis man fx. søger i en søgemaskine, så henter man
også bare data.

Hvis man derimod fx. skriver et indlæg i et www-forum, så sender man data,
man "gør noget". Det samme hvis man sender filer, sletter noget osv.

På det mere tekniske plan kan jeg nævne disse forskelle:

Det er begrænset hvor meget data man kan sende i en GET-request. Jeg kan
ikke lige huske hvor meget. Normalt er man (eller i hvert fald jeg) langt
væk fra grænsen, enten den ene eller den anden vej.

En POST-side kan (eller bør) ikke reloades. Mange browsere fungerer på denne
måde:
1) Brugeren submitter en form, der benytter POST
2) Brugeren kommer så ind på en "POST-side"
3) Brugeren vælger "reload" i sin browser
4) Inden browseren kontakter serveren kommer den med en advarsel, inden man
fortsætter.

Denne advarsel er (så vidt jeg husker) ret uforståelig i IE. I fx. Netscape
mener jeg at advarslen er skrevet meget tydeligt, men ca. lige så
uforståeligt hvis man ikke har forstand på HTTP.

Advarslen kommer fordi browseren ved brugeren er på en POST-side, og "ved"
dermed at da brugern gik ind på siden "gjorde" brugeren noget. Bliver siden
reloadet ved at poste de samme data igen, gør man det, man gjorde før,
igen.
Browseren Konqueror håndterer det på en anden måde. Trykker man "reload" på
en POST-side, bliver den hentet igen via GET, og post-data er kasseret.
Det er både godt og skidt. :)
Vil man "poste" igen kan man dog blot vælge "tilbage", og submitte igen.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Wed, 16 Oct 2002 16:57:31 +0200, Niels Andersen
<niels-usenet@myplace.dk> wrote:

>GET bruges når man surfer helt almindeligt rundt. Så laver man jo ikke andet
>end at modtage data. Hvis man fx. søger i en søgemaskine, så henter man
>også bare data.

http://www.w3.org/Provider/Style/Input.html nævner endda specifikt:

"There is no commitment by the user. The operation can be undone
simply by pressing the Back button on a browser. The user can never be
held responsible for anything which was done using HTTP GET."

>Advarslen kommer fordi browseren ved brugeren er på en POST-side, og "ved"
>dermed at da brugern gik ind på siden "gjorde" brugeren noget. Bliver siden
>reloadet ved at poste de samme data igen, gør man det, man gjorde før,
>igen.

Problemet er dog her, at man bare vil se siden (hvis man fx er bladret
tilbage til den), og kan vælge mellem:

1. at sende informationerne igen (hvilket man ikke ønsker)
2. at få en tekstbesked om at siden er expired (hvilket man er
ligeglad med)

Ingen af mulighederne er egentligt interessante.

--
- Peter Brodersen

---

Peter Brodersen wrote in <aok6vl$ib2$1@dknews.tiscali.dk>:
>>Advarslen kommer fordi browseren ved brugeren er på en POST-side, og "ved"
>>dermed at da brugern gik ind på siden "gjorde" brugeren noget. Bliver
>>siden reloadet ved at poste de samme data igen, gør man det, man gjorde
>>før, igen.
>
> Problemet er dog her, at man bare vil se siden (hvis man fx er bladret
> tilbage til den), og kan vælge mellem:
>
> 1. at sende informationerne igen (hvilket man ikke ønsker)
> 2. at få en tekstbesked om at siden er expired (hvilket man er
> ligeglad med)
>
> Ingen af mulighederne er egentligt interessante.

Det har du ret i, for mig at se er det dårligt design af browseren samt brud
af HTTP-specifikationen. Det står tydeligt i RFC 2616 ("Hypertext Transfer
Protocol -- HTTP/1.1") i kapitel 13.13 at "tilbage"-funktionen skal vise
siden som den så ud, da man kom ind på den. Der skal altså ikke reloades,
serveren skal slet ikke kontaktes, når man går tilbage i history.

Problemet vil altså i teorien slet ikke opstå i forbindelse med
"tilbage"-funktionen, men kun med "reload".

Jeg har dog undet en metode til at omgå det, og jeg har endnu ikke fundet
nogen ulemper ved det, eller en browser hvor det ikke fungerer som
beskrevet. (Og selv hvis det ikke fungerer som beskrevet, så bør det dog
fungere problemfrit alligevel.)

1) Brugeren submitter en post-form
2) Serveren modtager data og behandler dem
3) Serveren sender et (http) redirect til en side, som viser resultatet

I de browsere jeg har testet, vil "tilbage" gå til siden med formen. Den
tomme "mellemside" er ikke i history, og man kan altså ikke komme hen til
den igen uden at submitte formen igen.
Dermed vil brugeren aldrig se den uforståelige advarsel.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Thu, 17 Oct 2002 01:58:34 +0200, Niels Andersen
<niels-usenet@myplace.dk> wrote:

>Problemet vil altså i teorien slet ikke opstå i forbindelse med
>"tilbage"-funktionen, men kun med "reload".

Jeg har ligeledes været irriteret i Netscape 4-tiden over at den var
ekstremt hurtig til at expire POST'ede sider.

Sikkert i god tro, men ulempen var, at man bl.a. ikke kunne printe en
POST'et side ud (her fik man blot en udprintet side med den kedelige
besked om at siden var expired pga. post-data) eller kigge i
kildeteksten på samme (hvor man blot fik HTML'en til den kedelige
besked etc.).

>1) Brugeren submitter en post-form
>2) Serveren modtager data og behandler dem
>3) Serveren sender et (http) redirect til en side, som viser resultatet

Jeg er selv blevet ganske positivt stemt overfor denne opførsel, og
bruger den oftere og oftere. Jeg gider dog sjældent at have "ekstra"
sider, der submittes til, så normalt submitter siden til sig selv,
hvorefter kode i starten af filen "gør hvad der skal gøres", og
redirect'er så til sig selv.

Jeg må dog indrømme, at jeg her kl. halv fire ikke tør stå inde for
reglerne om redirect af POST'ed data.

>I de browsere jeg har testet, vil "tilbage" gå til siden med formen. Den
>tomme "mellemside" er ikke i history, og man kan altså ikke komme hen til
>den igen uden at submitte formen igen.

Det har også den fordel, at der heller ingen skade sker, hvis folk
reloader den side, de er nået frem til. Dette kan ellers være ganske
normalt at man lidt overraskende bliver spurgt, om man vil submitte
data igen, hvis man fx logger ind på et nyhedssite, og fem minutter
efter bare reloader siden, for at se om der er sket noget nyt.

--
- Peter Brodersen

---

Peter Brodersen wrote in <aol3gp$js1$1@dknews.tiscali.dk>:
> Jeg må dog indrømme, at jeg her kl. halv fire ikke tør stå inde for
> reglerne om redirect af POST'ed data.

Den vil jeg gerne have uddybet lidt. :)

Når jeg redirecter i den forbindelse plejer der ikke at være data med, eller
måske kun lille smute data, som sendes som get-data, altså i querystring.

> Det har også den fordel, at der heller ingen skade sker, hvis folk
> reloader den side, de er nået frem til. Dette kan ellers være ganske
> normalt at man lidt overraskende bliver spurgt, om man vil submitte
> data igen, hvis man fx logger ind på et nyhedssite, og fem minutter
> efter bare reloader siden, for at se om der er sket noget nyt.

Lige præcis. :)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Thu, 17 Oct 2002 11:22:26 +0200, Niels Andersen
<niels-usenet@myplace.dk> wrote:

>> Jeg må dog indrømme, at jeg her kl. halv fire ikke tør stå inde for
>> reglerne om redirect af POST'ed data.
>Den vil jeg gerne have uddybet lidt. :)

Jeg mindes "noget om" at hvis man POST'er til en URL, der redirecter,
så kan det tænkes at browserne så blot vælger også at POST'e til den
nye URL, hvis det fx er en 301 Permanently Moved. Men sådan hænger det
vist ikke sammen i praksis - ellers har jeg vist en del hobbysider,
der burde være faldet fra hinanden :)

Jeg har stadig ikke fået tjekket RFC2616.

--
- Peter Brodersen

---

Kasper Johansen wrote:

>Hej gruppe...
>
>Jeg sidder og overvejer at bruger GET-metoden i stedet for POST da den er
>betydeligt hurtigere. Men jeg kan godt forestille mig at den giver problemer
>da alle data bliver skrevet oppe i stien til siden.
>
>Er der nogle der har dårlige/gode erfaringer med dette??
>
>----
>Mvh Kasper
>www.cszone.h4f.dk
>www.levithan.h4f.dk
>
>
>
>
brug post når det er nødvendigt ( fil transfer ) eller lange url (
standarden siger 255 tegn, men oftest kan både browserne og servere
fortolke længere urler)

brug ellers post når ->
1) du vil forhindre dine brugere at bookmarke resultat siden, og
andre at linke til den. ( det kan der jo være gode grunde til )
2) genere de 90% af brugerne der bruger IE, og nu for en side
med advarsel!... brugte post.... tryk reload for at se siden ... når
brugerne bruger back knappen i browseren


--
mvh Hans