---

Hej

Er der nogen derude der har oplevet at deres sites Sessionvariable pludselig
allesammen bliver tomme ?
Vi har fået det problem, det sker for en del brugere. Det startede med en
der skrev ind da han fik fejl. Vi kunne se på fejlen at det var ved åbning
af databasen - DSN'en holdes i en sessionvariabel da den kan være variabel.
Vi kunne ikke finde fejlen, og satte derfor en On Error Resume ind i den
funktion der åbner vores database.
Når fejlen opstår, skriver vi alle HTTP_headere, alle sessionvariable samt
databasens fejlmeddelelse ind i en mail og sender til os selv for at se hvem
der har problemer, hvor det opstår osv. Det uploadede vi i går til middag.
Her til morgen lå der 49 mails derfra.

Det sker som sagt på forskellige sider i sitet ( altså når de et stykke før
sessionerne går ned ). Alle deres sessionvariable er tomme, ikke kun den med
databasen. Vi har søgt alle sider igennem efter Session.Abandon +
Session.Timeout og der ligger problemet tilsyneladene ikke ( Session.Abandon
bruges kun ved logud samt alt for mange forsøg på at logge ind,
Session.Timeout er sat til en time )

Alene her til morgen er der ankommer ti mails i skrivende stund, så alle
forslag til hvad grunden kan være er meget, meget velkomne.....

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> skrev i en meddelelse
news:ap87g4$d63$1@sunsite.dk...
[snip]

Jeg har lidt mere information:

Vores site er integreret i en hjemmeside der ligger i et andet directory (
her er der taget højde for IE6.0's forhold til trediepartscookies )
Dvs. at nogle menupunkter tilhører os, og nogle tilhører "det oprindelige"
site.

Vi har lige fundet to grunde til at dette kan ske ude på internet:
1) Filreplikering
2) Antivirus programmer

Er der nogen der ved noget om det ?
Hver nat replikeres databasen ( men fejlen kommer på alle døgnets timer )
På serveren er der installeret McAffee antivirus.

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote in message
news:ap87g4$d63$1@sunsite.dk...
> Er der nogen derude der har oplevet at deres sites Sessionvariable
pludselig
> allesammen bliver tomme ?

Session variable er sat for hver bruger, for at identificere brugeren
skriver ASP en session cookie i brugerens browser så brugeren kan
identificeres udfra denne cookie næste gang han/hun henter en side.
Hvis brugeren har slået session cookies fra vil han/hun få en ny session
hver gang han/hun henter en ny side.
(du kan fx selv slå session cookies fra i din browser og afprøve dit site)

1) Hvorfor gemmer i egentligt connectionstringen i en session variabel?
2) Hvornår sætter i connection stringen til det den skal være
(initialiserer)
Det lyder umiddelbart som en undeligt løsning at smide sin connectionstring
i en session variabel..

MVH
Allan Ebdrup

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> skrev i en meddelelse
news:ap8i9g$197h$1@news.cybercity.dk...
> "Chrisser" <cbj@egdatainform.dk> wrote in message
> news:ap87g4$d63$1@sunsite.dk...
> > Er der nogen derude der har oplevet at deres sites Sessionvariable
> pludselig
> > allesammen bliver tomme ?
>
> Session variable er sat for hver bruger, for at identificere brugeren
> skriver ASP en session cookie i brugerens browser så brugeren kan
> identificeres udfra denne cookie næste gang han/hun henter en side.
> Hvis brugeren har slået session cookies fra vil han/hun få en ny session
> hver gang han/hun henter en ny side.
> (du kan fx selv slå session cookies fra i din browser og afprøve dit site)

Det er ikke problemet, vi fanger dem der har cookies slået fra og sender dem
til en særlig side, og jeg kan af HTTP_headerne se, at den cookie der
indeholder SessionID sendes med....

> 1) Hvorfor gemmer i egentligt connectionstringen i en session variabel?

Vi har mange kunder der benytter sig af disse sider, selv om de har hver
deres site og hver deres database, dvs. at siderne er så generelle som
muligt ( en slags fælles opdatering ).

> 2) Hvornår sætter i connection stringen til det den skal være
> (initialiserer)

DSN bliver så overført via Querystring til en index-side der sætter
sessionen. Altså er det styret af links ved de enkelte kunder.

> Det lyder umiddelbart som en undeligt løsning at smide sin
connectionstring
> i en session variabel..
>
Ja, jeg har været inde på at den skal afløses af en applicationsvariabel,
men det løser ikke vores problem med sessionerne, symptomet er jo i dette
tilfælde bare at kaldet til databasen fejler. Hvis vi ser bort fra det, vil
det næste symptom være at brugerne skal logge ind hele tiden fordi deres
userID forsvinder ( og i øvrigt hvad vi ellers har i vores sessioner)

Så uanset hvordan det med DSN'en løses ( andre forslag end min
applikationsvariabel er velkomne da jeg kun kan se de to løsninger ), ja så
har jeg brug for at finde ud af hvad der går galt...


Chrisser

---

Jeg har lige haft et meget lignende problem - efter et stykke tid 'tabte' et
site konsekvent folks sessions.

Problemet viste sig at skyldes, at jeg ifm. en ny funktionalitet var begyndt
at gemme en _lang_ række cookies hos brugerne (clientside via JS) - her løb
jeg tilsyneladende ind i "max 20 cookies pr. host/server"-begrænsningen, og
så 'røg' ASP-session-cookien. Jeg gemte 2 cookies pr. side, og når jeg i en
session havde besøgt ca. 10 sider, gik det galt.

Måske I for nylig har implementeret noget lignende?

Min løsning var at... 'optimere' mit cookie-forbrug(!).

- Christian


"Chrisser" <cbj@egdatainform.dk> wrote in message
news:ap8jrn$3ak$1@sunsite.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> skrev i en meddelelse
> news:ap8i9g$197h$1@news.cybercity.dk...
> > "Chrisser" <cbj@egdatainform.dk> wrote in message
> > news:ap87g4$d63$1@sunsite.dk...
> > > Er der nogen derude der har oplevet at deres sites Sessionvariable
> > pludselig
> > > allesammen bliver tomme ?
> >
> > Session variable er sat for hver bruger, for at identificere brugeren
> > skriver ASP en session cookie i brugerens browser så brugeren kan
> > identificeres udfra denne cookie næste gang han/hun henter en side.
> > Hvis brugeren har slået session cookies fra vil han/hun få en ny session
> > hver gang han/hun henter en ny side.
> > (du kan fx selv slå session cookies fra i din browser og afprøve dit
site)
>
> Det er ikke problemet, vi fanger dem der har cookies slået fra og sender
dem
> til en særlig side, og jeg kan af HTTP_headerne se, at den cookie der
> indeholder SessionID sendes med....
>
> > 1) Hvorfor gemmer i egentligt connectionstringen i en session variabel?
>
> Vi har mange kunder der benytter sig af disse sider, selv om de har hver
> deres site og hver deres database, dvs. at siderne er så generelle som
> muligt ( en slags fælles opdatering ).
>
> > 2) Hvornår sætter i connection stringen til det den skal være
> > (initialiserer)
>
> DSN bliver så overført via Querystring til en index-side der sætter
> sessionen. Altså er det styret af links ved de enkelte kunder.
>
> > Det lyder umiddelbart som en undeligt løsning at smide sin
> connectionstring
> > i en session variabel..
> >
> Ja, jeg har været inde på at den skal afløses af en applicationsvariabel,
> men det løser ikke vores problem med sessionerne, symptomet er jo i dette
> tilfælde bare at kaldet til databasen fejler. Hvis vi ser bort fra det,
vil
> det næste symptom være at brugerne skal logge ind hele tiden fordi deres
> userID forsvinder ( og i øvrigt hvad vi ellers har i vores sessioner)
>
> Så uanset hvordan det med DSN'en løses ( andre forslag end min
> applikationsvariabel er velkomne da jeg kun kan se de to løsninger ), ja
så
> har jeg brug for at finde ud af hvad der går galt...
>
>
> Chrisser
>
>
>

---

"Christian Estrup" <ces@visualcom.dk> skrev i en meddelelse
news:3db7e7af$0$28781$edfadb0f@dspool01.news.tele.dk...
> Jeg har lige haft et meget lignende problem - efter et stykke tid 'tabte'
et
> site konsekvent folks sessions.
>
> Problemet viste sig at skyldes, at jeg ifm. en ny funktionalitet var
begyndt
> at gemme en _lang_ række cookies hos brugerne (clientside via JS) - her
løb
> jeg tilsyneladende ind i "max 20 cookies pr. host/server"-begrænsningen,
og
> så 'røg' ASP-session-cookien. Jeg gemte 2 cookies pr. side, og når jeg i
en
> session havde besøgt ca. 10 sider, gik det galt.
>

Hmm, mener du at det kan være på serversiden at der kan være en begrænsning
på cookies ?
I det vi får sendt tilbage kan jeg bla. se:

HTTP_COOKIE:ASPSESSIONIDGQQQQMEU=KFIAINBDKGBIIMCBOGOHLDMK

- så brugerens browser har cookien med sessionsID'en

Men hvis du snakker om en begrænsning på serversiden, så vil det jo faktisk
sige at når nr 21 starter og så ryger nr 1 ud, og der kan så reelt kun være
20 brugere af gangen ???

Er det en opsætning på serveren ?

For hvis jeg har forstået dette ret kan det jo meget vel være det der går
galt, sitet har en hel del besøgende...

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> escribió

> Men hvis du snakker om en begrænsning på serversiden, så vil det jo
faktisk
> sige at når nr 21 starter og så ryger nr 1 ud, og der kan så reelt
kun være
> 20 brugere af gangen ???

Nej, der er tale om at for hver bruger er der et begrænset antal
cookies der kan sættes.
På trods af at du ser en session-cookie, kan det faktisk godt være
dit problem. Forestil dig følgende:

*clienten starter session (session-cookie sættes)
*clienten surfer rundt på sitet
*max antal cookies nås -> session cokkien bliver slettet
*Cliente klikker på et nyt link
*En ny sessioncookie bliver sat, uden tilhørrende varibler -> Fejl på
siden -> email sendes, men med id fra den nye session.

Med venlig hilsen
Lars Hoffmann

---

"Lars Hoffmann" <lars@intercambiodvd.com> skrev i en meddelelse
news:ap8qgr$sg329$1@ID-163022.news.dfncis.de...
>
> Nej, der er tale om at for hver bruger er der et begrænset antal
> cookies der kan sættes.
> På trods af at du ser en session-cookie, kan det faktisk godt være
> dit problem. Forestil dig følgende:
>
> *clienten starter session (session-cookie sættes)
> *clienten surfer rundt på sitet
> *max antal cookies nås -> session cokkien bliver slettet
> *Cliente klikker på et nyt link
> *En ny sessioncookie bliver sat, uden tilhørrende varibler -> Fejl på
> siden -> email sendes, men med id fra den nye session.
>

Jo, men hvad så når vi ikke selv sætter nogle cookies.....vi bruger kun
sessioner, er der en begrænsning på det ?
Selv om vores sider er integreret i sitet, ligger de ikke i samme domaine,
vi har af samme grund haft problemer med at især IE6.0 opfattede vores
sessions som trediepartscookies...
så selv om "værtssiden" måske sætter cookies så burde det vel ikke tælle,
vel ?
- og alle links der henter vores sider ind i sitet kører igennem vores
index-fil som sætter sessionerne ( hvis de klikker på flere af vores links
i træk bliver sessionerne vel bare overskrevet ?)

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> skrev i en meddelelse
news:ap8rf4$7g9$1@sunsite.dk...
>
> Selv om vores sider er integreret i sitet, ligger de ikke i samme domaine,
> vi har af samme grund haft problemer med at især IE6.0 opfattede vores
> sessions som trediepartscookies...

domaine = to virtueller mapper på samme server

> så selv om "værtssiden" måske sætter cookies så burde det vel ikke tælle,
> vel ?

Jeg har lige tjekket min pc for cookies, og jeg har ingen fra deres site, så
det gør de ikke !

Ser ud til at vi er på bar bund igen ?


Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> Er der nogen derude der har oplevet at deres sites Sessionvariable
pludselig
> allesammen bliver tomme ?

Jeg skyder lige lidt fra hoften:

Kører der et virusprogram som kommer forbi Global.asa og derved "genstarte"
applikationen?

Du er sikker på at i ikke bruger flere forskellige virtual websites? (
<http://support.microsoft.com/?scid=kb;en-us;Q173307> )

Har i sikret jer at i ikke disabler sessionstate på nogle sider vha.
ENABLESESSIONSTATE = False

Har i tjekket om der er en sammenhæng mellem hvilke browsere der bruges, IE6
er lidt speciel på det område (
<http://support.microsoft.com/?scid=kb;en-us;Q293222> )

Er du sikker på at der ikke er "unormale" karakterer i domænenavnet? (
<http://support.microsoft.com/?scid=kb;en-us;Q316112> )

Bruger du frames? ( <http://support.microsoft.com/?scid=kb;en-us;Q178037> )

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:ap92hh$1qnb$1@news.cybercity.dk...
>
> Jeg skyder lige lidt fra hoften:

Fint !!!

> Kører der et virusprogram som kommer forbi Global.asa og derved
"genstarte"
> applikationen?

McAfee ASaP er installeret, jeg ved ikke hvad du mener med om den kommer
forbi Global.asa, er det om den scanner den og den derved opfattes som
ændret ?
Men jeg har ladet mig fortælle at allerede oprettede sessioner i det
tilfælde får lov at køre færdig...er det rigtigt ?

> Du er sikker på at i ikke bruger flere forskellige virtual websites? (
> <http://support.microsoft.com/?scid=kb;en-us;Q173307> )

Vi gør ikke, men vores sider ligger i et virtuelt directory, og webstedets i
et andet, hvert link der fører til vores sider går derfor igennem en
index-fil, der sætter sessions. Jeg har testet ved at klikke på alt i
vilkårlig rækkefølge, med og uden at have logget ind, det virker godt nok.

> Har i sikret jer at i ikke disabler sessionstate på nogle sider vha.
> ENABLESESSIONSTATE = False

Ja

> Har i tjekket om der er en sammenhæng mellem hvilke browsere der bruges,
IE6
> er lidt speciel på det område (
> <http://support.microsoft.com/?scid=kb;en-us;Q293222> )

Ja, det er ikke kun IE6.0 det sker for, også 5.5 og 5.01 har vi "fået mails
fra".
Og der er taget højde for cookies/session indstillinger.

>
> Er du sikker på at der ikke er "unormale" karakterer i domænenavnet? (
> <http://support.microsoft.com/?scid=kb;en-us;Q316112> )

Ja

> Bruger du frames? (
<http://support.microsoft.com/?scid=kb;en-us;Q178037> )

I dette tilfælde nej, vores sider hentes dog ind i deres via frames. Hos
andre kunder bruger vi frames, der er tilsyneladene ingen problemer...
Der bruges: IIS 5.0 ( vistnok )

Herudover:
Deres linie ud er stofanet, kan det have nogen betydning ?

MVH
Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> McAfee ASaP er installeret, jeg ved ikke hvad du mener med om den kommer
> forbi Global.asa, er det om den scanner den og den derved opfattes som
> ændret ?
> Men jeg har ladet mig fortælle at allerede oprettede sessioner i det
> tilfælde får lov at køre færdig...er det rigtigt ?

<http://support.microsoft.com/?scid=kb;en-us;Q303881>

PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes noget med
deres cache eller evt. proxy?

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:apbl5b$1gc4$1@news.cybercity.dk...
> "Chrisser" <cbj@egdatainform.dk> wrote
> > McAfee ASaP er installeret, jeg ved ikke hvad du mener med om den kommer
> > forbi Global.asa, er det om den scanner den og den derved opfattes som
> > ændret ?
> > Men jeg har ladet mig fortælle at allerede oprettede sessioner i det
> > tilfælde får lov at køre færdig...er det rigtigt ?
>
> <http://support.microsoft.com/?scid=kb;en-us;Q303881>

Det vil sige at IIS bare venter på et "hul" i forespørgslerne.... ja, det er
jo ikke helt det samme som at vente på at sessionerne løber ud...


> PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes noget
med
> deres cache eller evt. proxy?
>

Ja, det ved jeg jo ikke, jeg ved kun at serveren åbenbart kører på en
stofa-forbindelse.

Er der en måde hvorpå jeg kan se brugerens forbindelse, vi får som sagt de
HTTP-headers der forefindes, men der kan jeg jo ikke se noget om deres
forbindelse. Kan man få den vist ?

Chrisser

---

Chrisser wrote :

> Er der en måde hvorpå jeg kan se brugerens forbindelse, vi får som
> sagt de HTTP-headers der forefindes, men der kan jeg jo ikke se noget
> om deres forbindelse. Kan man få den vist ?

hvad mener du med det ? TCP-kommunikationen imellem klient og server er
"connection-oriented", men selve HTTP-kommunikationen er "state-less".

Kan du uddybe det lidt ?



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B560C2E5288spamstocholmdk@130.226.1.34...
> Chrisser wrote :
>
> > Er der en måde hvorpå jeg kan se brugerens forbindelse, vi får som
> > sagt de HTTP-headers der forefindes, men der kan jeg jo ikke se noget
> > om deres forbindelse. Kan man få den vist ?
>
> hvad mener du med det ? TCP-kommunikationen imellem klient og server er
> "connection-oriented", men selve HTTP-kommunikationen er "state-less".
>
> Kan du uddybe det lidt ?
>

Jo da....
Jacob Andersen skrev til mig:

"PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes noget med
deres cache eller evt. proxy?"

- og så vil jeg gerne have at vide om jeg på nogen måde kan se om de ramte
har stofanet, jeg kan ikke se noget i den retning ud fra deres
HTTP-headers...


Chrisser

---

Chrisser wrote :

> "Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
> news:Xns92B560C2E5288spamstocholmdk@130.226.1.34...
>> Chrisser wrote :
>>
>> > Er der en måde hvorpå jeg kan se brugerens forbindelse, vi får som
>> > sagt de HTTP-headers der forefindes, men der kan jeg jo ikke se
>> > noget om deres forbindelse. Kan man få den vist ?
>>
>> hvad mener du med det
>> Kan du uddybe det lidt ?

> Jacob Andersen skrev til mig:
>
> "PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes
> noget med deres cache eller evt. proxy?"
>
> - og så vil jeg gerne have at vide om jeg på nogen måde kan se om de
> ramte har stofanet, jeg kan ikke se noget i den retning ud fra deres
> HTTP-headers...

ok ... så finder du blot det IP-range, som Stofanet bruger, og så
sammenligner du dette med IP-adressen i dine requests. Jeg tror, at du
kan slå disse ranges op ved ripe.net, men jeg er ikke sikker.



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B5662B1C346spamstocholmdk@130.226.1.34...
>
> > Jacob Andersen skrev til mig:
> >
> > "PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes
> > noget med deres cache eller evt. proxy?"
> >
> > - og så vil jeg gerne have at vide om jeg på nogen måde kan se om de
> > ramte har stofanet, jeg kan ikke se noget i den retning ud fra deres
> > HTTP-headers...
>
> ok ... så finder du blot det IP-range, som Stofanet bruger, og så
> sammenligner du dette med IP-adressen i dine requests. Jeg tror, at du
> kan slå disse ranges op ved ripe.net, men jeg er ikke sikker.
>

Tak, det vil jeg da lige prøve at kigge lidt på

Chrisser

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B5662B1C346spamstocholmdk@130.226.1.34...
>
> ok ... så finder du blot det IP-range, som Stofanet bruger, og så
> sammenligner du dette med IP-adressen i dine requests. Jeg tror, at du
> kan slå disse ranges op ved ripe.net, men jeg er ikke sikker.
>
Hov !
Den eneste IP-adresse jeg får tilbage, er på host'en.
Så nu er jeg jo nødt til at spørge om hvordan jeg får brugerens ip-adresse
ud ?


Chrisser

---

Chrisser wrote :

> "Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
> news:Xns92B5662B1C346spamstocholmdk@130.226.1.34...
>>
>> ok ... så finder du blot det IP-range, som Stofanet bruger, og så
>> sammenligner du dette med IP-adressen i dine requests. Jeg tror, at
>> du kan slå disse ranges op ved ripe.net, men jeg er ikke sikker.
>>
> Den eneste IP-adresse jeg får tilbage, er på host'en.
> Så nu er jeg jo nødt til at spørge om hvordan jeg får brugerens
> ip-adresse ud ?

du kan se lidt om, hvad du kan læse i headeren på requests på
http://asp.stocholm.dk/servervariables.asp



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B56A638C665spamstocholmdk@130.226.1.34...
> >>
> > Den eneste IP-adresse jeg får tilbage, er på host'en.
> > Så nu er jeg jo nødt til at spørge om hvordan jeg får brugerens
> > ip-adresse ud ?
>
> du kan se lidt om, hvad du kan læse i headeren på requests på
> http://asp.stocholm.dk/servervariables.asp
>

Jeg troede faktisk, at når jeg bad om Request.ServerVariables("ALL_HTTP"),
så fik jeg alt hvad der var at få....

Ved du så hvilken af disse der giver brugerens IP: "LOCAL_ADDR" eller
"REMOTE_ADDR" ?

PS:Du havde ret med ripe.net, jeg har fundet nogle IP-ranges derinde, det er
bare en skam at jeg så ikke har brugerens IP på alle de fejl der er kommet
mail om.....

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> skrev i en meddelelse
news:apj0nq$mri$1@sunsite.dk...
>
> Ved du så hvilken af disse der giver brugerens IP: "LOCAL_ADDR" eller
> "REMOTE_ADDR" ?
>
Jeg har lige fundet ud af at det må være "REMOTE_ADDR" da den på din side
returnerer vores firewall....


Chrisser

---

Chrisser wrote :

> "Chrisser" <cbj@egdatainform.dk> skrev i en meddelelse
> news:apj0nq$mri$1@sunsite.dk...
>>
>> Ved du så hvilken af disse der giver brugerens IP: "LOCAL_ADDR" eller
>> "REMOTE_ADDR" ?
>>
> Jeg har lige fundet ud af at det må være "REMOTE_ADDR" da den på din side
> returnerer vores firewall....

det lyder rimeligt ... :)


--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B576659DAD6spamstocholmdk@130.226.1.34...
> >>
> > Jeg har lige fundet ud af at det må være "REMOTE_ADDR" da den på din
side
> > returnerer vores firewall....
>
> det lyder rimeligt ... :)
>

Ja, til gengæld var det faktisk urimligt af mig at spørge om noget, som jeg
kan slå op i min ASP-bog.
Den eneste undskyldning jeg lige kan finde på, er noget med mandag...

Fra min ASP-bog:
"REMOTE_ADDR: IP address of the client that issued the HTTP request"


Chrisser

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:apbl5b$1gc4$1@news.cybercity.dk...
>
> PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes noget
med
> deres cache eller evt. proxy?
>
Nu har jeg fået gang i at tjekke om de kører på stofa som en fællesnævner.
Det med proxy tror jeg vi kan se bort fra, når man ser på et eksempel på en
header:

HTTP-headers:
HTTP_ACCEPT:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
*/* HTTP_ACCEPT_LANGUAGE:da HTTP_CONNECTION:Keep-Alive
HTTP_HOST:xxx.xx.xxx.xx
HTTP_REFERER:http://xxx.xx.xxx.xx/xxxxxxx/xxxxxxxxxxxx.asp

HTTP_USER_AGENT:Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
HTTP_COOKIE:ASPSESSIONIDGQQQQJGU=ANCDEKNBLPJOBJOJMAPMJBGK

HTTP_VIA:1.0 PROXY

- det er de færreste mails der indeholder sidste linie, det må vel være det
samme som at det er de færreste der kører vis proxy ???

MVH
Chrisser

---

Chrisser wrote :

> "Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
> news:apbl5b$1gc4$1@news.cybercity.dk...
>>
>> PS: Hvis alle brugerne der er ramt har stofanet kunne det skyldes
>> noget med deres cache eller evt. proxy?
>>
> Nu har jeg fået gang i at tjekke om de kører på stofa som en
> fællesnævner. Det med proxy tror jeg vi kan se bort fra, når man ser
> på et eksempel på en header:
[snip]
> HTTP_VIA:1.0 PROXY
>
> - det er de færreste mails der indeholder sidste linie, det må vel
> være det samme som at det er de færreste der kører vis proxy ???

er der overhovedet nogen emails, der indeholder denne sidste linie ?

Mine requests indeholder pt linien HTTP_VIA 1.1 THOR, og det er der sådan
set ikke noget mærkeligt i ... andre gange indeholder den
HTTP_X_FORWARDED_FOR 130.xxx.xxx.xxx



--
Jesper Stocholm
http://stocholm.dk
Overvejer du at købe bøger ved saxo.dk ? Kig først på
http://www.firmcheck.dk/Info.asp?website=www.saxo.dk

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns92B5989C3C191spamstocholmdk@130.226.1.34...
> >>
> > Nu har jeg fået gang i at tjekke om de kører på stofa som en
> > fællesnævner. Det med proxy tror jeg vi kan se bort fra, når man ser
> > på et eksempel på en header:
> [snip]
> > HTTP_VIA:1.0 PROXY
> >
> > - det er de færreste mails der indeholder sidste linie, det må vel
> > være det samme som at det er de færreste der kører vis proxy ???
>
> er der overhovedet nogen emails, der indeholder denne sidste linie ?

Ja, en 3-7 stykker.
+ et par stykker med: HTTP_VIA 1.1 [vilkårlige bogstaver]

> Mine requests indeholder pt linien HTTP_VIA 1.1 THOR, og det er der sådan
> set ikke noget mærkeligt i ... andre gange indeholder den
> HTTP_X_FORWARDED_FOR 130.xxx.xxx.xxx

Jeg har set FORWARDED en enkelt gang...

Nu er der kommet 40-50 mails med IP-adresse:
Nogle fra folk med stofanet (med og uden cache og/eller proxy)
Nogle fra alle mulige andre IP-adresser

Der ser ikke ud til at være noget system i dette, så er jeg tilbage ved
mistanken om antivirusprogram kontra Global.asa...

Hvor tit mon antivirusprogrammet scanner Global.asa ? (disse mails kommer jo
fordelt over hele døgnet)
Vil det være sikkerhedsmæssigt at sætte antivirusprogrammet op til ikke at
scanne Global.asa (hvis det altså kan lade sig gøre), eller kan man placere
virus i Global.asa ?

Nu er dette måske udenfor gruppen (selv om mange af jer bruger Global.asa
?), men jeg ville være glad for nogle hints før vi skal til at bede vores
kunde om ikke at scanne denne fil (det ville være så dumt hvis det var
uforsvarligt).


Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> Vil det være sikkerhedsmæssigt at sætte antivirusprogrammet op til ikke at
> scanne Global.asa (hvis det altså kan lade sig gøre), eller kan man
placere
> virus i Global.asa ?

Sæt virusprogrammet op til at undlade at scanne Global.asa, og lav så en
scheduled scan af filen engang i døgnet.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:apjnm5$16bu$1@news.cybercity.dk...
> "Chrisser" <cbj@egdatainform.dk> wrote
> > Vil det være sikkerhedsmæssigt at sætte antivirusprogrammet op til ikke
at
> > scanne Global.asa (hvis det altså kan lade sig gøre), eller kan man
> placere
> > virus i Global.asa ?
>
> Sæt virusprogrammet op til at undlade at scanne Global.asa, og lav så en
> scheduled scan af filen engang i døgnet.
>
Det være hermed gjort, og der strømmer stadig mails ind...
Så er den udelukket.

Jeg fik den tanke om IIS står og genstarter pga nogle ukendte, ydre
omstændigheder, Men så skulle den jo gøre det 4-20 gange i timen, og så
ville folk vel slet ikke kunne få fat i siden mens genstarten står på ?
Det tror jeg vi ville have fået en reaktion på....

Bar bund igen igen

Chrisser

---

Chrisser wrote :

> "Jakob Andersen" <jakob@effectus.dk> skrev
>> "Chrisser" <cbj@egdatainform.dk> wrote
>> Sæt virusprogrammet op til at undlade at scanne Global.asa, og lav så
>> en scheduled scan af filen engang i døgnet.
>>
> Det være hermed gjort, og der strømmer stadig mails ind...
> Så er den udelukket.
>
> Jeg fik den tanke om IIS står og genstarter pga nogle ukendte, ydre
> omstændigheder, Men så skulle den jo gøre det 4-20 gange i timen, og
> så ville folk vel slet ikke kunne få fat i siden mens genstarten står
> på ? Det tror jeg vi ville have fået en reaktion på....

kan du selv genskabe problemet ? Sker det også for dig, hvis du surfer
rundt på websitet ?


--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <spam200210@stocholm.dk> skrev i en meddelelse
news:Xns92B673CAA97CCspamstocholmdk@130.226.1.34...
>
> kan du selv genskabe problemet ? Sker det også for dig, hvis du surfer
> rundt på websitet ?
>
Det kan jeg faktisk ikke, jeg har prøvet. Jeg har både prøvet at opføre mig
som en "normal" bruger, og også at klikke på alt hvad der er at klikke på -
springe rundt i siderne mm. Sitet opfører sig perfekt når jeg er derinde...

Vi har nu heller ikke fået klager fra kunden, men jeg bryder mig ikke om at
det kun sker på det bestemte websted og ikke på de andre, der benytter de
samme filer. For mig indikerer det er der er noget galt et eller andet sted
deroppe ...

Jeg sidder ved windows xp pro 2002 med IE6.0
- men af de indkomne mails kan jeg se at det er forskellige windowsversioner
og forskellige IE'er.

Dog vil jeg mene, at der er en pæn overvægt af win98 og winNT(4.0 +5.0),
samt overvægt af IE5.5 og IE6.0
- men det er sikkert meget normalt ?

Chrisser

---

Chrisser wrote :

> "Jesper Stocholm" <spam200210@stocholm.dk> skrev i en meddelelse
> news:Xns92B673CAA97CCspamstocholmdk@130.226.1.34...
>>
>> kan du selv genskabe problemet ? Sker det også for dig, hvis du
>> surfer rundt på websitet ?
>>
> Det kan jeg faktisk ikke, jeg har prøvet. Jeg har både prøvet at
> opføre mig som en "normal" bruger, og også at klikke på alt hvad der
> er at klikke på - springe rundt i siderne mm. Sitet opfører sig
> perfekt når jeg er derinde...
>
> Vi har nu heller ikke fået klager fra kunden, men jeg bryder mig ikke
> om at det kun sker på det bestemte websted og ikke på de andre, der
> benytter de samme filer. For mig indikerer det er der er noget galt et
> eller andet sted deroppe ...

et skud: kan det ikke skyldes, at en bruger forlader sin PC og vender
tilbage (meget) senere og vil fortsætte ? Problemerne skulle vel ikke
tilfældigvis peake omkring frokost eller aftensmad ? Hvis du har mange
brugere på dit site, så er det vel ikke decideret mærkeligt, at nogle af
dem (på noget ADSL-noget som Stofanet) forlader deres PC logget på jeres
website ... og når de vender tilbage er deres session løbet ud ?

Jeg var på et tidspunkt med til at lave en intranet applikation, hvor vi
specifikt beregnede timeout-tidsintervallet ud fra, hvor lang tid folk i
gennemsnit gik til frokost. De havde nemlig en tendens til at starte med at
arbejde med programmet ... og så lige gå 45 mins til frokost ... og så
arbejde videre.



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <spam200210@stocholm.dk> skrev i en meddelelse
news:Xns92B67874D3D5Espamstocholmdk@130.226.1.34...
>
> et skud: kan det ikke skyldes, at en bruger forlader sin PC og vender
> tilbage (meget) senere og vil fortsætte ? Problemerne skulle vel ikke
> tilfældigvis peake omkring frokost eller aftensmad ? Hvis du har mange
> brugere på dit site, så er det vel ikke decideret mærkeligt, at nogle af
> dem (på noget ADSL-noget som Stofanet) forlader deres PC logget på jeres
> website ... og når de vender tilbage er deres session løbet ud ?

Joo, og det sker helt sikkert også, men vores session Timeout er på en time,
og jeg synes ikke at de indkomne mails topper specielt omkring
frokost/aftensmad. De tager blot af om natten hvilket er meget normalt da de
fleste sover

Jeg har bare lidt svært ved at tro at så mange brugere i lige bestemt ét
område i jylland alle forlader deres pc'ere i over en time, mens det ikke
sker i andre jyske områder.

Jeg selv kan da godt finde på at lade mine sider "hænge" på arbejde, men det
er da for dyrt derhjemme...

> Jeg var på et tidspunkt med til at lave en intranet applikation, hvor vi
> specifikt beregnede timeout-tidsintervallet ud fra, hvor lang tid folk i
> gennemsnit gik til frokost. De havde nemlig en tendens til at starte med
at
> arbejde med programmet ... og så lige gå 45 mins til frokost ... og så
> arbejde videre.

Vi har nu bare sat den til en time fordi disse sessions er så
vigtige.....der findes også en del administrative sider, der betjenes af
vores kunder, der har vi sat session timeout til 2 timer.

Jeg er nu løbet tør for ideer.....
Chrisser

---

Chrisser wrote :

> "Jesper Stocholm" <spam200210@stocholm.dk> skrev i en meddelelse
> news:Xns92B67874D3D5Espamstocholmdk@130.226.1.34...
>>
>> et skud: kan det ikke skyldes, at en bruger forlader sin PC og vender
>> tilbage (meget) senere og vil fortsætte ? Problemerne skulle vel ikke
>> tilfældigvis peake omkring frokost eller aftensmad ? Hvis du har
>> mange brugere på dit site, så er det vel ikke decideret mærkeligt, at
>> nogle af dem (på noget ADSL-noget som Stofanet) forlader deres PC
>> logget på jeres website ... og når de vender tilbage er deres session
>> løbet ud ?
>
> Jeg har bare lidt svært ved at tro at så mange brugere i lige bestemt
> ét område i jylland alle forlader deres pc'ere i over en time, mens
> det ikke sker i andre jyske områder.

var du ikke blevet enig med dig selv om, at de fleste kom fra stofanet ?
Stofanet er mig bekendt ikke i alle jyske byer - omend det vist ikke
findes herovre på Sjælland.

> Jeg selv kan da godt finde på at lade mine sider "hænge" på arbejde,
> men det er da for dyrt derhjemme...

Præcist ... og derfor kunne det godt være, at det netop var opførslen i
de områder, hvor Stofanet var muligt.

> Jeg er nu løbet tør for ideer.....

tja ... jeg er også lidt blank ... det sidste var blot et skud fra hoften
....



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <spam200210@stocholm.dk> skrev i en meddelelse
news:Xns92B67BAD1F1BAspamstocholmdk@130.226.1.34...
> >
> > Jeg har bare lidt svært ved at tro at så mange brugere i lige bestemt
> > ét område i jylland alle forlader deres pc'ere i over en time, mens
> > det ikke sker i andre jyske områder.
>
> var du ikke blevet enig med dig selv om, at de fleste kom fra stofanet ?
> Stofanet er mig bekendt ikke i alle jyske byer - omend det vist ikke
> findes herovre på Sjælland.

Nej det var jeg egentlig ikke...jeg vil (uden at have talt de nu langt over
400 mails) sige at op mod halvdelen kommer fra stofanet.
Men der er vel også mange...
Kundens server kører på stofanet, men kan det have en betydning ?

Det fremgår af stofas hjemmeside, stofa.net, at det også findes på både fyn
og sjælland
Men vi får slet ingen mails fra de andre sites, som har brugere fra andre af
de større jydske byer (stofanet eller ej)

> tja ... jeg er også lidt blank ... det sidste var blot et skud fra hoften

- det var kedeligt
Jeg tror at jeg er nødt til at lade den ligge for nu,. jeg synes at jeg har
tjekket alle jeres ideer uden at have fundet noget at sætte fingeren på.

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> Kundens server kører på stofanet, men kan det have en betydning ?

Nu ved jeg ikke hvordan stofanet helt specifikt fungerer, men egentlig er
dit problem jo i bund og grund et problem med server eller forbindelse så
prøv at spørge i dels news:dk.edb.system.ms-windows.server og
news:dk.edb.netvaerk (eller hvor spørgsmål om stofanet nu hører hjemme) det
kan jo være der er andre der har haft problemer med sessionstate hvis de
hoster på en stofanetforbindelse.

> Men vi får slet ingen mails fra de andre sites, som har brugere fra andre
af
> de større jydske byer (stofanet eller ej)

Og er de sites også hosted på samme maskine på en stofanetforbindelse?

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:aplvla$8q2$1@news.cybercity.dk...
>
> Og er de sites også hosted på samme maskine på en stofanetforbindelse?
>

Det må jeg sige nej til....de andre sider hoster vi selv på en server der
ikke kører på stofanet.
Der er altså to klare forskelle:

1) Problemsitet ligger på en server der kører på en stofanet-forbindelse.
2) Problemsitet er, som det eneste (men vistnok ikke det sidste !!!),
integreret i et andet site som vi ikke har haft indflydelse på.

Nogle gode idéer på bedding ???

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> 1) Problemsitet ligger på en server der kører på en stofanet-forbindelse.

Som sagt så spørg i enten netwærk eller windows.server om der er noget
specielt med at hoste på Stofanet.

> 2) Problemsitet er, som det eneste (men vistnok ikke det sidste !!!),
> integreret i et andet site som vi ikke har haft indflydelse på.

Er du sikker på at brugerne ikke bruger over en time på ikke asp sider der
gør at sessionen timer ud?

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:apm4pk$eof$1@news.cybercity.dk...
> "Chrisser" <cbj@egdatainform.dk> wrote
> > 1) Problemsitet ligger på en server der kører på en
stofanet-forbindelse.
>
> Som sagt så spørg i enten netwærk eller windows.server om der er noget
> specielt med at hoste på Stofanet.

Ok, det vil jeg gøre

> > 2) Problemsitet er, som det eneste (men vistnok ikke det sidste !!!),
> > integreret i et andet site som vi ikke har haft indflydelse på.
>
> Er du sikker på at brugerne ikke bruger over en time på ikke asp sider der
> gør at sessionen timer ud?
>
Jeg kan jo ikke være sikker, men vi snakker om mange brugere, for mange
efter min mening. Jeg kan næsten ikke tro at så mange forlader deres pc med
en internetforbindelse kørende i over en time....
Samt det faktum at et par stykker har indsendt et screendump af fejlen til
vores kunde - det var det der startede det hele....

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote
> Jeg kan jo ikke være sikker, men vi snakker om mange brugere, for mange
> efter min mening. Jeg kan næsten ikke tro at så mange forlader deres pc
med
> en internetforbindelse kørende i over en time....

Det kender jeg rigtig mange der gør, også på arbejdspladser hvor
browservinduet blot ligger i baggrunden og herefter tager det frem efter de
har lavet noget andet.

Men så vidt jeg husker bevares sessionstate ikke på rene HTML sider og
derfor kan det godt være derfor den timer ud?

Men prøv evt. at "tracke" de brugere det går galt med i logfilen altså,
finde alle deres request og på denne måde se hvornår de er kommet og hvor
lang pause der har været i deres requests før de får fejlen.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> skrev i en meddelelse
news:apmafq$moa$1@news.cybercity.dk...
>
> Det kender jeg rigtig mange der gør, også på arbejdspladser hvor
> browservinduet blot ligger i baggrunden og herefter tager det frem efter
de
> har lavet noget andet.

Ja, på arbejde gør jeg det også selv, men ikke derhjemme hvor jeg selv
betaler


> Men så vidt jeg husker bevares sessionstate ikke på rene HTML sider og
> derfor kan det godt være derfor den timer ud?

Det vidste jeg ikke, vi har dog, så vidt jeg ved, ingen rene html-sider, men
måske kunden har. Jeg vil i hvertfald tjekke det...

> Men prøv evt. at "tracke" de brugere det går galt med i logfilen altså,
> finde alle deres request og på denne måde se hvornår de er kommet og hvor
> lang pause der har været i deres requests før de får fejlen.
>

Det var nu nok ingen dårlig ide, men det kan tidligst blive i næste uge der
bliver tid til det !

Jeg vil takke jer for jeres tid alle jeres gode ideer i forbindelse med mit
problem. Når jeg får rigtig tid til at rode med det kan det være jeg samler
al den information jeg kan finde om situationen, og sender det ud i gruppen
igen.


Chrisser