---

Hvad gør Response.End, som nogle gange ses i forbindelse med
Response.Redirect eller Response.Write?

Hvornår er det hensigtsmæssigt at anvende den/ikke anvende den?

Anders Lau
--
Anders Lau Mandsholm
Aabyhoej, Denmark
www.mandsholm.dk
lau@mandsholm.ingenspamtak.dk

---

"Anders Lau Mandsholm" <lau@mandsholm.ingenspamtak.dk> wrote in message
news:3b0fe38a.7747855@news.stofanet.dk...
> Hvad gør Response.End, som nogle gange ses i forbindelse med
> Response.Redirect eller Response.Write?

Response.end stopper eksekveringen af filen og returnere det hidtige output.

> Hvornår er det hensigtsmæssigt at anvende den/ikke anvende den?

Når du skal have stoppet eksekveringen

Hvis du f.eks. i en eksekvering finder ud af at en bruger ikke har adgang
til denne side kan du bruge noget ala dette:

Response.clear
response.write "Du har ikke adgang til dette"
Response.end

--
Jakob Andersen
FAQ for webdesign gruppen på
<http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "

---

"Jakob Andersen" <jakob@andersen.as> wrote in message
news:9eoped$9b0$1@sunsite.dk...
> Response.clear
> response.write "Du har ikke adgang til dette"
> Response.end

Går selvfølgelig ud fra at Buffer = True i overnstående eksempel
--
Jakob Andersen
FAQ for webdesign gruppen på
<http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "

---

On Sat, 26 May 2001 19:30:43 +0200, "Jakob Andersen"
<jakob@andersen.as> wrote:

>Går selvfølgelig ud fra at Buffer = True i overnstående eksempel

- hvilket gav mig anledning til at spørge, hvad det lige præcist er
den der
Response.Buffer = True
gør?

Alle steder anbefales, at man bruger den i toppen af alle sine sider.
Forklaringerne synes jeg til gengæld ikke altid er lige forståelige,
men det skyldes sikkert mit manglende kendskab til, hvordan en
ASP-server virker.

Det billede jeg har dannet mig i mit hoved er nogenlunde sådan:
Hvis Buffer = false, så vil ASP-scriptet sende output (HTML) afsted
efterhånden som den afvikler koden, mens Buffer = True får den til at
opsamle hele dokumentet og så afsende det hele til sidst.
Resultat: Færre overførsler og mindre serverbelastning.
Man kan så bruge Response.Flush til at sende "klumper" afsted
undervejs, hvis man tror, outputtet er stort.

Er det nogenlunde korrekt forstået - eller er det bare hjemmefilosofi?

Kan nogen forklare, om der er situationer, hvor man *ikke* bør bruge
Buffer = True? Eller om der er ulemper i bestemte situationer?

Og hvad er sammenhængen med Redirect?
Er det blot, at sikre, at modtageren ikke ser noget, hvis der
alligevel kommer et Redirect et eller andet i koden?
Eller (der dukker et eller andet op af den langsomme memory) har det
noget at gøre med, at man ikke kan skrive Redirect efter andre
HTTP-headere?

Mvh. Jørn

--
Jørn Andersen
Brønshøj

---

"Jørn Andersen" wrote:
>
> hvad det lige præcist er den der
> Response.Buffer = True
> gør?
>
> Det billede jeg har dannet mig i mit hoved er nogenlunde sådan:
> Hvis Buffer = false, så vil ASP-scriptet sende output (HTML) afsted
> efterhånden som den afvikler koden, mens Buffer = True får den til
> at opsamle hele dokumentet og så afsende det hele til sidst.
> Resultat: Færre overførsler og mindre serverbelastning.
> Man kan så bruge Response.Flush til at sende "klumper" afsted
> undervejs,

Nemlig. Der ryger simpelthen færre (men større) ip-pakker over nettet.

> hvis man tror, outputtet er stort.

Nej, man bruger Response.Flush så brugeren kan begynde at bruge siden
inden den er helt færdig og så hun kan se at der sker noget.

> Kan nogen forklare, om der er situationer, hvor man *ikke* bør
> bruge Buffer = True? Eller om der er ulemper i bestemte
> situationer?

Næ, det skulle lige være på sider, som fungerer som statusmeddelelser,
men der kan man jo blot gøre bruge af response.flush .

> Og hvad er sammenhængen med Redirect?
> [...]
> Eller (der dukker et eller andet op af den langsomme memory) har
> det noget at gøre med, at man ikke kan skrive Redirect efter
> andre HTTP-headere?

Næsten, en opfording til klienten om at redirecte, sender serveren som
en http-header (helt præcis som "location: http://min.url.dk/bla/") og
da http-header'e (som navnet antyder) skal stå i toppen af
http-strømmen, må der ikke være sendt noget af http-kroppen inden man
prøver at redirecte.

--
Lauritz

---

On Sun, 27 May 2001 13:13:05 +0200, Lauritz Jensen
<lauritz2@hotmail.com> wrote:

Hej Lauritz,

Tak for svaret.

<SNIP>
>> hvis man tror, outputtet er stort.
>
>Nej, man bruger Response.Flush så brugeren kan begynde at bruge siden
>inden den er helt færdig og så hun kan se at der sker noget.

OK.

Hvad er "almindelig praksis" (TM) i den sammenhæng?
Hvis man på Internet har en almindelig husmands-database med nogle få
hundrede poster fordelt over en god håndfuld tabeller, hvor man laver
simple udtræk og enkle skrivninger, vil man så:
a) normalt ikke bruge Flush?
b) bruge Flush efter "HTML-standard-elementer" (altså før eksekvering
af sidens hoved-SQL)?
c) bruge flere Flush undervejs?

Jeg så i øvrigt også et sted, at man skulle være varsom med Flush,
hvis brugerne sidder på langsomme forbindelser, da Flush kræver
tilbagesvar, før den går videre.

>> Kan nogen forklare, om der er situationer, hvor man *ikke* bør
>> bruge Buffer = True? Eller om der er ulemper i bestemte
>> situationer?
>
>Næ, det skulle lige være på sider, som fungerer som statusmeddelelser,
>men der kan man jo blot gøre bruge af response.flush .

Ikke forstået. Hvilken type statusmeddelelser tænker du på?

<SNIP resten>


Mvh. Jørn

--
Jørn Andersen
Brønshøj

---

"Jørn Andersen" wrote:
>
> Hvis man på Internet har en almindelig husmands-database med nogle
> få hundrede poster fordelt over en god håndfuld tabeller, hvor man
> laver simple udtræk og enkle skrivninger, vil man så:
> a) normalt ikke bruge Flush?
> b) bruge Flush efter "HTML-standard-elementer" (altså før
> eksekvering af sidens hoved-SQL)?
> c) bruge flere Flush undervejs?

Det kommer an på[tm] hvor store og langsomme dine sider er. Hvis det
tager et halvt milisekundt at generer siden er der ingen grund til at
bruge flush (ligegyldigt hvor stor siden så ellers er), da det bliver
sendt så hurtigt til brugeren. Hvis din side tager 2 minutter at lave
(så skal du optimerer din kode!) og flyder 200kb, så kunne du måske
sende en flush for hver 40kb ...
(selv om jeg har lavet noget mere end en husmandsdatabase, er flush ikke
noget af det, jeg har brugt mest)

> Jeg så i øvrigt også et sted, at man skulle være varsom med Flush,
> hvis brugerne sidder på langsomme forbindelser, da Flush kræver
> tilbagesvar, før den går videre.

Hvis du bruger flush for meget har du jo samme situaltion/problem, som
hvis du brugte Buffer=False

> >> Kan nogen forklare, om der er situationer, hvor man *ikke* bør
> >> bruge Buffer = True? Eller om der er ulemper i bestemte
> >> situationer?
> >
> >Næ, det skulle lige være på sider, som fungerer som statusmeddelelser,
> >men der kan man jo blot gøre bruge af response.flush .
>
> Ikke forstået. Hvilken type statusmeddelelser tænker du på?

Hvis du havde en side, der lavede en stor batch routine, så kunne det
være output kun bestod af "opretter ..., 3 % færdig", "flytter .., 4.5 %
færdig", "hopper ..., 7.3 % færdig" ... og så skulle der flushes efter
hver linie ... men det var nok bare for at sige, at der ikke rigtig er
nogen steder, hvor du ikke skal bruge Buffer=True.

--
Lauritz

---

On Mon, 28 May 2001 07:52:54 +0200, Lauritz Jensen
<lauritz2@hotmail.com> wrote:

>(selv om jeg har lavet noget mere end en husmandsdatabase, er flush ikke
>noget af det, jeg har brugt mest)

Tak - det var noget i den retning jeg efterlyste.

<SNIP>
>> Ikke forstået. Hvilken type statusmeddelelser tænker du på?
>
>Hvis du havde en side, der lavede en stor batch routine, så kunne det
>være output kun bestod af "opretter ..., 3 % færdig", "flytter .., 4.5 %
>færdig", "hopper ..., 7.3 % færdig" ... og så skulle der flushes efter
>hver linie ...

Nåh, sådan, nu forstår jeg.

> men det var nok bare for at sige, at der ikke rigtig er
>nogen steder, hvor du ikke skal bruge Buffer=True.

Jamen, så har jeg vist forstået det vigtigste.

Mvh. Jørn


--
Jørn Andersen
Brønshøj