---

Hej i gruppen

Vi har et site hvor klienter kan logge ind og over ssl (https) kan se
fortrolige data.

Blandt disse informationer er der jpg-billeder. Da det ikke umiddelbart
kan lade sig gøre at undgå at "folk" kan "gætte" URLen til et sådant
billede, har vi lagt billederne et niveau før roden af sitet og lader et
asp-script undersøge om de har lov til at hente billedet, og nu er jeg ved
at nå til essensen af problemet.

ASP-scriptet som er helt standard, á la:
"check om rettighederne er i orden"
....
stmdata.LoadFromFile
strFilePath Response.ContentType = "image/jpeg"
Response.BinaryWrite stmData.Read
stmData.Close
Response.End
....
virker helt perfekt. Billederne er ml. 1 og 20 Kbyte og der er sider hvor
der vises op til et par hundreder i en tabel. Umiddelbart virker det som
det skal og det er relativt hurtigt/hurtigt nok...
men... nogle enkelte billeder tager op til flere minutter at downloade...
og det er ikke så godt

Jeg har fundet frem til nogle af de problematiske billeder (få stk.) og
størrelsesmæssigt er de absolut ikke anderledes end de tusinder af andre
billeder på sitet.
Jeg har prøvet at lave et debugsite, hvorfra det var muligt at hente
billederne på forskellige måder. Jeg har noteret nedenfor hvile der var
langsomme og hvilke der var normal downloadhastighed på:
- hurtig - uden ssl direkte via URLen
- hurtig - direkte via URLen med ssl
- hurtig - uden ssl via asp-scriptet
- langsom - via aspscriptet med ssl

Ovenstående er afprøvet med IE60sp2 på XPsp2 (fuldt opdateret).

For sjov afprøvede jeg med en beta-Mozilla og den havde ingen problemer.

Er der nogen der kender til problemer á la ovenstående?

Jeg har p.t. ikke mulighed for at poste en af de problematiske jpg's, men
kan sige så meget at den (ligesom alle de andre uproblematiske billeder)
er konverteret fra pcx-format vha irfanview 3.92.

En af mine ideer for at omgå problemet er at bruge et andet program til at
konvertere den problematiske jpg, men jeg så heller at problemet blev løst


/Jens Ulrik

---

"Jens U. K." <1jk2@3bsopatent4.dk> wrote
> ASP-scriptet som er helt standard, á la:
> "check om rettighederne er i orden"
> ...
> stmdata.LoadFromFile
> strFilePath Response.ContentType = "image/jpeg"
> Response.BinaryWrite stmData.Read
> stmData.Close
> Response.End
> ...

Når du streamer bliver billederne indlæst i hukommelsen og derefter streamet
ud. Mit umiddelbare gæt på hvorfor dit problem opstår er at der ikke bliver
ryddet op i hukommelsen og derfor bliver Stream komponenten nødt til at
vente til der bliver ryddet op af IIS(Dog harmonerer denne antagelse ikke
med det faktum at det virker med mozilla men det er mit bedste bud). Husker
du i ovenstående kode at sætte stmData lig med "Nothing"?

Nu nævner du at det drejer sig om tusindvis af billeder, hvis det er
tilfældet ville jeg personligt nok også tøve med at benytte ADO's stream
objekt og istedet indbygge dit rettighedstjek i et ISAPI filter(der findes
færdige af slagsen) så du slipper for at have filerne liggende udenfor
webscope og dermed skal streame dem igennem en komponent.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@intellect.invalid> wrote in message
news:41a49167$0$13744$ba624c82@nntp03.dk.telia.net...

> Når du streamer bliver billederne indlæst i hukommelsen og derefter
> streamet ud. Mit umiddelbare gæt på hvorfor dit problem opstår er at der
> ikke bliver ryddet op i hukommelsen og derfor bliver Stream komponenten
> nødt til at vente til der bliver ryddet op af IIS(Dog harmonerer denne
> antagelse ikke

Nej, vel.

> med det faktum at det virker med mozilla men det er mit bedste bud).
> Husker du i ovenstående kode at sætte stmData lig med "Nothing"?

Ja.

>
> Nu nævner du at det drejer sig om tusindvis af billeder, hvis det er
> tilfældet ville jeg personligt nok også tøve med at benytte ADO's stream

Hvorfor?

> objekt og istedet indbygge dit rettighedstjek i et ISAPI filter(der
> findes

Jeg tror ikke jeg får lov til at installere sådan et på en webudbyders
server. Jeg har dog ikke undersøgt det.

> færdige af slagsen) så du slipper for at have filerne liggende udenfor
> webscope og dermed skal streame dem igennem en komponent.

Har du et eksempel/link/dokumentation på og erfaring med et sådant
ISAPI-filter?
Evt. også med at få det installeret hos en webudbyder?

Du skriver slet ikke nogen kommentarer til det faktum at "fejlen" kun sker
over en ssl-forbindelse... det undrer mig. Det er i hvert fald det primære
emne jeg har ledt efter "bug-reports" på google med (og dog ikke rigtig
fundet nogen).
Jeg mener at det må være kombinationen af IE og SSL og en (måske)
fejlagtig formatteret jpg-fil.

Jeg oplever btw. også "fejlen" på en intern testserver med replikerede
data.

/Jens Ulrik

---

"Jens U. K." <1jk2@3bsopatent4.dk> wrote
> Har du et eksempel/link/dokumentation på og erfaring med et sådant
> ISAPI-filter?
> Evt. også med at få det installeret hos en webudbyder?

Her er et eksempel på et hjemmelavet:
<http://www.codeproject.com/isapi/authfilter.asp>

Mht. installation må du snakke med din udbyder. De kan nøjes med at
installere det på din side men de vil nok også gerne gå din kode igennem for
fejl da det er lidt mere kritisk at afvikle denne kode end alm. ASP.

Grunden til at jeg vil anbefale dette fremfor ADO's stream er at det giver
bedre performance og hurtigere frigivelse af hukommelse.

> Du skriver slet ikke nogen kommentarer til det faktum at "fejlen" kun sker
> over en ssl-forbindelse... det undrer mig. Det er i hvert fald det primære
> emne jeg har ledt efter "bug-reports" på google med (og dog ikke rigtig
> fundet nogen).
> Jeg mener at det må være kombinationen af IE og SSL og en (måske)
> fejlagtig formatteret jpg-fil.


Det kunne jeg også sagtens forestille mig, nu kom jeg bare med umiddelbare
skud fra hoften og da serveren også bruger en del processorkraft når den
skal kryptere kunne jeg forestille mig at man ramte et loft.

> Jeg oplever btw. også "fejlen" på en intern testserver med replikerede
> data.

Hvordan ser ram/cpu forbrug ud her under eksekvering?

--
Jakob Andersen

---

"Jakob Andersen" <jakob@intellect.invalid> wrote in message
news:41a4b72b$0$13775$ba624c82@nntp03.dk.telia.net...
> "Jens U. K." <1jk2@3bsopatent4.dk> wrote
>> Har du et eksempel/link/dokumentation på og erfaring med et sådant
>> ISAPI-filter?
>> Evt. også med at få det installeret hos en webudbyder?
>
> Her er et eksempel på et hjemmelavet:
> <http://www.codeproject.com/isapi/authfilter.asp>

Jeg har ikke member-adgang til det site, og kan ikke lige vurdere nu om
jeg vil have det
Men er ovenstående eksempel noget du selv har kørende?
Hvilken webudbyder har du som tillader de ændringer der skal til ifm
filteret?

> Grunden til at jeg vil anbefale dette fremfor ADO's stream er at det
> giver bedre performance og hurtigere frigivelse af hukommelse.

Har du links eller info til hvor meget bedre perfomance vil blive?
Typisk er det max. 200 filer af ml. 1 og 20 KBytes, der bliver streamet på
"en" gang - dvs. de bliver streamet en ad gangen, men havner på samme
side. Så i alt er det i gns. max. 2 MByte på en side. Størstedelen af
klienterne har dog ikke mere end 5-10 stk. billeder der skal vises.

>> Jeg mener at det må være kombinationen af IE og SSL og en (måske)
>> fejlagtig formatteret jpg-fil.
>
> Det kunne jeg også sagtens forestille mig, nu kom jeg bare med
> umiddelbare skud fra hoften og da serveren også bruger en del
> processorkraft når den skal kryptere kunne jeg forestille mig at man
> ramte et loft.

Fint nok, men jeg skrev jo netop at det kun drejede sig om nogle enkelte
filer.

>
>> Jeg oplever btw. også "fejlen" på en intern testserver med replikerede
>> data.
>
> Hvordan ser ram/cpu forbrug ud her under eksekvering?

Det har jeg ikke kigget på endnu!

/Jens Ulrik

---

"Jens U. K." <1jk2@3bsopatent4.dk> wrote
> Jeg har ikke member-adgang til det site, og kan ikke lige vurdere nu om
> jeg vil have det

Ok, det er ellers et ganske fint site og det er gratis.

> Men er ovenstående eksempel noget du selv har kørende?

Ikke lige ovenstående men jeg har engang brugt et kommercielt produkt som så
vidt jeg husker hedder AuthentiX.

> Hvilken webudbyder har du som tillader de ændringer der skal til ifm
> filteret?

Det var på min arbejdsgivers egen server som jeg selv havde kontrol over.
Jeg har aldrig haft brug for det på et webhotel.

> Har du links eller info til hvor meget bedre perfomance vil blive?

Desværre ikke lige på stående fod.

> Typisk er det max. 200 filer af ml. 1 og 20 KBytes, der bliver streamet på
> "en" gang - dvs. de bliver streamet en ad gangen, men havner på samme
> side. Så i alt er det i gns. max. 2 MByte på en side. Størstedelen af
> klienterne har dog ikke mere end 5-10 stk. billeder der skal vises.

Okay, jeg havde bare et indtryk af at det var noget flere filer.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@intellect.invalid> wrote in message
news:41a4b72b$0$13775$ba624c82@nntp03.dk.telia.net...
> "Jens U. K." <1jk2@3bsopatent4.dk> wrote
[...]
>> Jeg oplever btw. også "fejlen" på en intern testserver med replikerede
>> data.
>
> Hvordan ser ram/cpu forbrug ud her under eksekvering?

Perfekt - intet at bemærke. Jeg afviklede siden direkte på serveren, den
var afsindig langsom (som forventet med den problemtaiske jpg-fil) men der
var intet at bemærke ved CPU-/RAM-forbruget.

/Jens Ulrik

---

Jens U. K. wrote:

> Jeg har fundet frem til nogle af de problematiske billeder (få stk.) og
> størrelsesmæssigt er de absolut ikke anderledes end de tusinder af andre
> billeder på sitet.

Du mener altså at noe er feil med selve bildefilene? Hvis de kan åpnes i
IE, Firefox, IrfanView m. fl. uten feilmeldinger så kan de jo ikke være
"korrupte". Hvis de ikke er korrupte, og de gir langsom nedlasting
uansett hvordan de grupperes sammen med andre bilder, ja da er jeg uten
svar

> - hurtig - uden ssl direkte via URLen
> - hurtig - direkte via URLen med ssl
> - hurtig - uden ssl via asp-scriptet
> - langsom - via aspscriptet med ssl

1) Redesign! Glem ssl, bildene ligger likevel beskyttet utenfor public
domain.
2) Redesign! Gi alle dine bilder unike navn av typen
2004887687srehsr-6857387hgh.jpeg og lagre navnene i en database f. ek.
sammen med en URI. Alternativt gi dine directorys unike navn som skifter
flere ganger om dagen.

> For sjov afprøvede jeg med en beta-Mozilla og den havde ingen problemer.

Hvis du kan teste dette litt mer så bør det være mulig å trekke en
sikker konklusjon.

> En af mine ideer for at omgå problemet er at bruge et andet program til
> at konvertere den problematiske jpg, men jeg så heller at problemet blev
> løst

Som sagt, hvis de problematiske bildene kan åpnes i ulike programmer
uten feilmeldinger så vil vel dette bare være å kaste bort tiden?

terje

---

"terje" <late@night.zz> wrote in message
news:30jlubF319ut4U1@uni-berlin.de...
> Jens U. K. wrote:
>
>> Jeg har fundet frem til nogle af de problematiske billeder (få stk.) og
>> størrelsesmæssigt er de absolut ikke anderledes end de tusinder af
>> andre billeder på sitet.
>
> Du mener altså at noe er feil med selve bildefilene? Hvis de kan åpnes i
> IE, Firefox, IrfanView m. fl. uten feilmeldinger så kan de jo ikke være
> "korrupte".

Definer korrupt
Det er alment kendt at et program kan have bugs og måske ligger problemet
i IE's jpg-fremviser-kode eller formentlig nærmere i IE's
ssl/dekrypterings-kode. Den problematiske jpg-fil er måske formateret på
en måde som gør at den "normalt" ikke er "korrupt", men når den ryger
igennem dekrypteringen ændres en eller andet bit og det trigger et
eller andet som sænker hastigheden gevaldigt.

> Hvis de ikke er korrupte, og de gir langsom nedlasting uansett hvordan
> de grupperes sammen med andre bilder, ja da er jeg uten svar

Også mig

[forslag om redesign]

Jeg vil helst undgå det, og desuden holder jeg af at vide hvorfor noget
ikke virker selvom det burde.

[...]
>> En af mine ideer for at omgå problemet er at bruge et andet program til
>> at konvertere den problematiske jpg, men jeg så heller at problemet
>> blev løst
>
> Som sagt, hvis de problematiske bildene kan åpnes i ulike programmer
> uten feilmeldinger så vil vel dette bare være å kaste bort tiden?

Nej det mener jeg ikke. Indholdet af filen vil jo ændres og forhåbentlig
gøre at IE's kode ikke trigger et eller andet som sænker hastigheden
gevaldigt.

/Jens Ulrik

---

Jens U. K. wrote:

> Definer korrupt

_corrupted data_

Hva viser Ctr+Alt+Del og CPU Usage når du laster ned bildene?

terje

---

"terje" <late@night.zz> wrote in message
news:30jnlpF2u4mrpU1@uni-berlin.de...
> Jens U. K. wrote:
>
>> Definer korrupt
>
> _corrupted data_
>
> Hva viser Ctr+Alt+Del og CPU Usage når du laster ned bildene?

Undskyld, det skulle jeg selvfølgelig have fortalt... der er intet at
bemærke, masser af overskud umiddelbart...

Men i mellemtiden har jeg prøvet at resmaple et af de problematiske
billeder. Det medførte at det ikke mere var problematisk!

Det kan være jeg skulle prøve at kontakte MS vedr. "fejlen"... nogen der
har erfaring med den slags. Jeg mener at det er mest oplagt at fejlen
ligger hos dem... i relation hertil var det jo faktisk også dem der havde
lavet en fejl i deres jpg-kommentar-parser som kunne udnyttes til "farlige
ting".

/Jens Ulrik

---

Jens U. K. wrote:

>> Hva viser Ctr+Alt+Del og CPU Usage når du laster ned bildene?
>
>
> Undskyld, det skulle jeg selvfølgelig have fortalt... der er intet at
> bemærke, masser af overskud umiddelbart...

Det skulle jo tyde på at problemet oppstår på serveren?
Hvis jeg var deg så ville jeg prøvd lykken i en av de store engelsk
språklige gruppene.

terje

---

"terje" <late@night.zz> wrote in message
news:30joutF30jcjmU1@uni-berlin.de...
> Jens U. K. wrote:
>
>>> Hva viser Ctr+Alt+Del og CPU Usage når du laster ned bildene?
>>
>>
>> Undskyld, det skulle jeg selvfølgelig have fortalt... der er intet at
>> bemærke, masser af overskud umiddelbart...
>
> Det skulle jo tyde på at problemet oppstår på serveren?

Hvordan det, når en mozillaklient klarer det fint?

> Hvis jeg var deg så ville jeg prøvd lykken i en av de store engelsk
> språklige gruppene.

Tjah.

/Jens Ulrik

---

Jens U. K. wrote:

>>> Undskyld, det skulle jeg selvfølgelig have fortalt... der er intet at
>>> bemærke, masser af overskud umiddelbart...
>>
>>
>> Det skulle jo tyde på at problemet oppstår på serveren?
>
>
> Hvordan det, når en mozillaklient klarer det fint?

Unnskyld meg, men hvorfor trekker du en masse konklusjoner når du ikke
engang har testet dette seriøst med flere browsere? Du har altså kun
testet med en "beta-Mozilla"?

terje

---

"terje" <late@night.zz> wrote in message
news:30kdsnF30j9fsU1@uni-berlin.de...
> Jens U. K. wrote:
>
>>>> Undskyld, det skulle jeg selvfølgelig have fortalt... der er intet at
>>>> bemærke, masser af overskud umiddelbart...
>>>
>>>
>>> Det skulle jo tyde på at problemet oppstår på serveren?
>>
>>
>> Hvordan det, når en mozillaklient klarer det fint?
>
> Unnskyld meg, men hvorfor trekker du en masse konklusjoner når du ikke
> engang har testet dette seriøst med flere browsere? Du har altså kun
> testet med en "beta-Mozilla"?

Jeg drager sikkert lidt for hurtige konklusioner nogen gange og det
indrømmer jeg gerne er ugodt, men i dette tilfælde mener jeg ikke at have
konkluderet noget. Jeg spørger blot til det ulogiske i at en serverfejl
(af den omtalte type) ikke viser sig i alle web-klienter.

Jeg er enig med dig i at man kan udføre 1000vis af forskellige
afprøvninger for at finde ud af hvor, hvorfor, osv. problemet opstår. Jeg
har allerede udført et par stykker af disse og har allerede brugt en del
tid på dette specifikke problem. Jeg har p.t. fundet ud af hvordan
problemet kan omgås i dette specifikke tilfælde, men ikke fundet selve
fejlen/fejlene. Hvis _jeg skulle_ finde fejlen er jeg sikker på at jeg
ville finde den jeg mener dog bare ikke at det er mit job. Jeg har
genskabt problemet på to forskellige servere på to forskellige lokationer
med med et par IE-klienter også fra forskellige lokationer... synes du
ikke det er nok information til at Microsoft selv kan lede videre efter
fejlen/fejlene?

Jeg har ikke i sinde at afprøve x antal browserklienter for at virke
seriøs i dine øjne

/Jens Ulrik