Tydal: är med på det, men det jag menade med att GET ligger i URL'en och POST i header är att i GET fallet så skickas det med i själva frågeraden (GET raden i header) medans i POST fallet ligger den i header (utanför frågeraden).
Så om man tar ditt exempel så blir det ungefär så här:
GET
[kod]
GET /newreply.php?do=postreply&s=&t=158652p=1333913&title=&messag e=Hello+World HTTP/1.1
Host: www.webforum.nu
Cookie: Den-inloggades-cookie
[/kod]
Tydal: är med på det, men det jag menade med att GET ligger i URL'en och POST i header är att i GET fallet så skickas det med i själva frågeraden (GET raden i header) medans i POST fallet ligger den i header (utanför frågeraden).
Om du är med på att postdata inte ligger i headern så tycker jag det är ett märkligt sätt att uttrycka sig.
Redigera in inlägget igen! [...] Det fanns ju ett gäng bra punkter som inte redan nämnts, in med dem! Seså, do it.
OK. Om herrar petimetrar slagits färdigt om huruvida det som står före eller efter den där blankraden i den "textfil" som skickas från klient till server är en "header" eller en "body" så kan jag väl göra det antar jag (det jag nu kommer ihåg av det jag skrev i den nattliga stundens ingivelse)
TriKri skrev:
Vad är egentligen skillnaden mellan POST och GET-data?
Som jag ser det:
Det man gör oavsett metod är att överföra namn-värdepar. Hur man än gör, lägs dessa i "klartext" (eller iallafall bara enklare "enkodat") i den "text" som förs över vid sidbegäran (det är den textens principer, dvs vad som är vad i ett HTTP-anrop - som diskuterats i hög detaljgrad här ovan i tråden).
Hursomhelst
Tre uppenbara sätt faller ut ganska omedelbums (se t.ex. länken i mitt första inlägg i tråden):
* GET - I URL.
* POST - i den "text" som skickas med sidbegäran
* i Cookies - dvs i en annan del av den "text" som skickas med vid sidbegäran (men här krävs i allmänhet lite fiffig script för att få in informationen i Cookien)
Man kan också, som påpekats tidigare i tråden, kombinera de tre och lägga sina namn-värdepar lite här och var efter tycke, smak och önskad effekt
Just GET lämpar sig i allmänhet antagligen sämre för att använda om du skall bygga kommandosystem/webbapplikationer med krav på säkerhet eftersom allt data (inklusive ev. sessionsID:n, AnvändarID:n eller lösenord) ligger i URLn - vilket öppnar för oavsiktliga missar och mindre önskvärda effekter om man inte ser upp...
Antag t.ex. att ett reklambrev från ditt webbhotell innehåller en personlig länk till din "kontrollpanel" på formen [kod]http://example.se/login.aspx?userid=jarvklo&password=MySecretPassword[/kod], men att den bara förekommer såhär:
[citat]Gå till din kontrollpanel [/citat] Antag nu att du vill rekommendera dem och att du vidarebefordrar reklambrevet till en polare...
Think about it!
Antag också att du byggt en WIKI och att du använder GET för alla kommandon (inkuslive http://example.se?page=apage&command=delete) och att Googles webbspindel får fatt i den webbplatsen... Oops!
TriKri skrev:
Kan man inte skicka data som varken syns i adressen eller som man måste skriva in i en textbox?
Jodå, med lite fiffig Javascript kan man skicka saker till och från en Applet som i sin tur kommunicerar med din server. En metod liknande den används t.ex. för BankID (även om man där antagligen tar steget fullt ut och låter appleten innehålla inmatningsfältet - jag har inte detaljanalyserat just den tjänsten )...
Men man kan också använda t.ex. XMLHttp (dvs i princip det som i dagligt tal kallas AJAX) för att skicka (XML-formaterad) data som aldrig förekommer i webbsidans adressfält eller i någon textbox på sidan.
OK. Om herrar petimetrar slagits färdigt om huruvida det som står före eller efter den där blankraden i den "textfil" som skickas från klient till server är en "header" eller en "body" så kan jag väl göra det antar jag
Det man gör oavsett metod är att överföra namn-värdepar.
Det är viktigt att poängtera detta, för standardtypen i ett formulär är just "namn-värdepar". Vill man ladda upp filer genom ett formulär måste man ändra typen genom ett tillägg i form-taggen:
Hur man än gör, lägs dessa i "klartext" (eller iallafall bara enklare "enkodat")
Kodningen som används kallas URL-kodning och används för att förbjudna tecken inte ska förekomma (tecken som har en särskild betydelse). Förbjudna tecken görs om till % följt av deras värde på hexadecimal form. Undantaget mellanslag som görs om till +.
En fördel (eller nackdel) med cookies är att informationen skickas automatiskt vid varje sidbegäran till samma domän utan att du behöver ange något. Om du inte tar bort cookien och användaren inte gör det så kommer den att vara kvar nästa gång användaren besöker sidan även om det är ett år senare.
Ett annat sätt att skicka information så den inte syns - som inte tagits upp, kanske för att den innebär att man inte skickar informationen alls - är sessioner. Med sessioner lagras all data på webbservern och lämnar aldrig den. I stället så är det ett så kallat sessions-ID som skickas runt med cookies. Varje användare får automatiskt ett unikt ID som sedan kopplas till en fil på webbservern med hans/hennes data.
Det är viktigt att poängtera detta, för standardtypen i ett formulär är just "namn-värdepar". Vill man ladda upp filer genom ett formulär måste man ändra typen genom ett tillägg i form-taggen:
multipart/formdata lämpar sig även om man har stora mängder data i input-fält då datan inte encodas.
tydal skrev:
En fördel (eller nackdel) med cookies är att informationen skickas automatiskt vid varje sidbegäran till samma domän utan att du behöver ange något. Om du inte tar bort cookien och användaren inte gör det så kommer den att vara kvar nästa gång användaren besöker sidan även om det är ett år senare.
Cookies försvinner normalt sett när man stänger ner webbläsaren om man inte angett expire-datum.
Kommentera