Page has Expired

[ulrikajosefsson]

Jag har ett adressregister i php/mysql där jag har en sök-funktion.

Sida 1: formulär för sökning

Sida 2: lista m sökresultaten + länk till ytterligare uppgifter

Sida 3: Personens kontaktinfo, samt länk tillbaka till sökresultatet. ( javascript: history.go(-1) ).

När man klickar på denna länken kommer man alltså till en sida där det står Warning Page has Expired. Det vill jag inte ha!

Uppstår detta bara vid postade variabler? Samma förfarande gäller för en lista i alfabetsordning (dock inget formulär utan en lista med bokstäver), och med en variabel som hängs på i url:en. Då funkar min bakåtknapp utmärkt. Finns det något sätt att undvika dessa "Page has Expired"-sidor?

 

/ulrikajosefsson

 

[TicoRoman]

Ett sätt är att posta formuläret med metoden GET istället för POST. Då 'hängs' variablerna på URLen och är där även när man 'backar' i webbläsaren.

 

Uppstår detta bara vid postade variabler?

Ja, om variablerna är postade med POST.

 

 

_________

TicoRoman - The One And Only

 

[ulrikajosefsson]

But of course! Det kunde jag ju räknat ut själv. Det måste ju fungera.

 

Det är bara det att jag är så van att formulär ska postas med POST...

 

[Cariad]

Jag brukar lösa det med att ha en mellansida som bara sparar informationen.

 

Använd dig alltså av ett POST-formulär, men direkt efter att all information har sparats, så skickar du om besökaren till en annan sida, med endast GET-variabler.

Detta gör du med header() och exit().

 

Sidan som tar emot skickad data:

mysql_query("INSERT data ...");
header("Location: skript.php?sparat=1");
exit;

Om du i dagsläget bygger upp hela sidan på samma ställe där informationen tas emot, så kan du ju använda dig av sessionsvariabler, och mellanlagra sidan. Bäst är så klart att ändra upplägget, men så här kan det se ut:

mysql_query("INSERT data ...");
$uniktID = uniqid("");
ob_start();
/* - - - - - */
echo "Sparad data här...";
/* - - - - - */
$_SESSION[$uniktID] = ob_get_contents();
ob_end_clean();
header("Location: skript.php?sparat=" . rawurlencode($uniktID));
exit;

Och detta är sidan som skriver ut sparad data:

echo $_SESSION[$_GET["sparat"]];

 

[Tillägg]

Jag glömde säga varför man ska använda sig av POST och inte GET: Storleken på skickad data! Med GET kan du inte skicka så mycket data... POST har ingen teoretisk begränsning.

[inlägget ändrat 2003-03-17 16:45:45 av Cariad]

[ulrikajosefsson]

Det det handlar om är alltså bara ett sökfält för adresser där man skriver in ett namn. Info skrivs in i databas på annan sida. Ditt sätt är nog jättebra men verkar nästan lite för avancerat för detta. Jag tror nog get räcker till för denna mängd data, hur mycket är max för get resp. post-metoden?

 

Nyfiken: Vad gör ob_start()?

 

[Cariad]

ob_start() påbörjar utbuffring. Alltså allt du skriver ut med exempelvis echo() och print(), mellanlagras i en buffert, och skickas inte direkt till användaren.

Sedan anropar vi ob_get_contents() för att få innehållet i bufferten, och till sist ob_end_clean() för att helt enkelt slänga bort allt i bufferten (rensa den utan att skriva ut det till användaren).

Men vi har datan sparad i sessions-variabeln, och kan använda oss av den senare.

 

Man gör på detta sätt för att huvuden, skickade med header(), måste komma före allt "innehåll", så om vi skriver ut något till besökaren kan vi inte sedan skicka header()-värdet.

 

När det gäller GET och POST så finns det ingen begränsning för de båda egentligen (enligt HTTP-specifikationerna). Så här säger RFC 2616:

The HTTP protocol does not place any a priori limit on the length of a URI. (...) A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle.

 

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Vad denna säger är alltså att man bör vara aktsam med adresser längre än 255 tecken, då dessa kan orsaka problem i äldre webbläsare/serverprogramvara.

Sedan finns det vissa andra program som har sin egen specifika gräns för adress-längden, vilket man aldrig kan veta exakt, så jag föreslår att man använder sig av POST i största möjliga utsträckning.