---

HJÆLP
Jeg har en side med shtml-filer (SSI)
siden er: www.lille-web.dk
Nu har jeg opdaget noget meget mærkeligt og uhyggeligt!

Hvis jeg efter alle min sider skriver en skråstreg ( / ) og bagefter
kommer den samme side frem igen dog uden CSS og billede. Den må opfatte
det som en side som ligger i en mappe hvor stien til CSS og billeder
ikke er den rigtige.

Men hvorfor skriver den ikke at siden ikke findes?

eks.
http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml
http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla

her er tilføjet /blablabla - en side som jeg ikke har lavet men den
vises! blablabla kan udskiftes med alt andet efter egent ønske! MEN DET
GØRE JEG IKKE!!!!

Hvis/når Google opdager dette vil den formodentlig straffe dette.

Jeg har prøvet med to test filer som kun har indeholdt koden: <p>En test
side</p> den ene fil ender på html den anden på shtml. html-filen laver
ikke denne "skygge side" men shtml filen opfører sig som beskrevet ovenfor.

Kan man evt "lukke" for disse "skygge sider" via .htaccess ?

:)
Morten

---

Morten P. Andersen skrev:
Hvorfor var det lige at jeg skrev den rigtige URL ..... værsgo Google!

---

Morten P. Andersen wrote:

> Hvorfor var det lige at jeg skrev den rigtige URL .....

Hvordan skulle vi ellers kunne se problemet?

> værsgo Google!

Du kan blokere googlebot og lignende i .htaccess - jeg husker ikke præcis
hvordan.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk/ - http://ginnerskov.dk/
http://html-faq.dk

---

Morten P. Andersen wrote:

> Men hvorfor skriver den ikke at siden ikke findes?
>
> eks.
> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml
> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla

Det er et spørgsmål om serveropsætning. Det har ikke nogen relevans i
html-gruppen. Link nr. 2 er fejlbehæftet og burde give en 404-fejl.

Jeg har ikke nogen ide om, hvilken gruppe det vil være relevant at spørge i.

> Kan man evt "lukke" for disse "skygge sider" via .htaccess ?

Sikkert, men det er heller ikke html-relevant. Prøv at spørge i php-gruppen,
måske de der ved det.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk/ - http://ginnerskov.dk/
http://html-faq.dk

---

Erik Ginnerskov skrev:

>
> Det er et spørgsmål om serveropsætning. Det har ikke nogen relevans i
> html-gruppen. Link nr. 2 er fejlbehæftet og burde give en 404-fejl.
>
Det menet jeg også men nu har jeg haft samme problem hos to forskellige
udbydere.

> Jeg har ikke nogen ide om, hvilken gruppe det vil være relevant at spørge i.
>
>> Kan man evt "lukke" for disse "skygge sider" via .htaccess ?
>
> Sikkert, men det er heller ikke html-relevant. Prøv at spørge i php-gruppen,
> måske de der ved det.
>
Jeg prøver der

---

On 22 Feb., 23:43, "Erik Ginnerskov" <erik.ginners...@live.dk> wrote:
> Morten P. Andersen wrote:
> > Men hvorfor skriver den ikke at siden ikke findes?
>
> > eks.
> >http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml
> >http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla

Hej Morten - jeg ved ikke, hvad problemet skyldes, men du kan i hver
faldt omgå den. Hvis du ændrer links til dine CSS-filer i toppen af
siden, således at de benytter en absolut sti, vil siderne vises med
den korrekte formattering igen.

Det ser jo ud til, at serveren tror, den befinder sig i en undermappe
til den korrekte mappe. Så stien ../css/lilleweb.css vil ikke længere
være korrekt. Men f.eks. /css/lilleweb.css burde få siden til at se
ordentlig ud igen, i alle tilfælde.

t

---

Tomasz Otap skrev:

> Hej Morten - jeg ved ikke, hvad problemet skyldes, men du kan i hver
> faldt omgå den. Hvis du ændrer links til dine CSS-filer i toppen af
> siden, således at de benytter en absolut sti, vil siderne vises med
> den korrekte formattering igen.
>
> Det ser jo ud til, at serveren tror, den befinder sig i en undermappe
> til den korrekte mappe. Så stien ../css/lilleweb.css vil ikke længere
> være korrekt. Men f.eks. /css/lilleweb.css burde få siden til at se
> ordentlig ud igen, i alle tilfælde.

Ja det er klart. Men mit problem er at jeg slet ikke vil have de andre
sider - med eller uden CSS

---

---

"Morten P. Andersen" <info@lille-web.dk> skrev i en meddelelse
news:4748b$47bf021e$5293ecbc$20429@news.arrownet.dk...
> HJÆLP
> Jeg har en side med shtml-filer (SSI)
> siden er: www.lille-web.dk
> Nu har jeg opdaget noget meget mærkeligt og uhyggeligt!
>
> Hvis jeg efter alle min sider skriver en skråstreg ( / ) og bagefter
> kommer den samme side frem igen dog uden CSS og billede. Den må opfatte
> det som en side som ligger i en mappe hvor stien til CSS og billeder ikke
> er den rigtige.
>
> Men hvorfor skriver den ikke at siden ikke findes?
>
> eks.
> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml
> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla
>
> her er tilføjet /blablabla - en side som jeg ikke har lavet men den vises!
> blablabla kan udskiftes med alt andet efter egent ønske! MEN DET GØRE JEG
> IKKE!!!!
>
> Hvis/når Google opdager dette vil den formodentlig straffe dette.
>
> Jeg har prøvet med to test filer som kun har indeholdt koden: <p>En test
> side</p> den ene fil ender på html den anden på shtml. html-filen laver
> ikke denne "skygge side" men shtml filen opfører sig som beskrevet
> ovenfor.
>
> Kan man evt "lukke" for disse "skygge sider" via .htaccess ?
>

Hvis det kan være til nogen hjælp...
I FF får jeg 3 fejl, hvis jeg prøver at åbne den sidste - altså den med
tilføjelsen der ikke hører til.

1
Stilarket http://www.lille-web.dk/sider/404.html blev ikke indlæst, fordi
dets MIME type, "text/html", ikke er "text/css".
http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla
Line 0

2
en fejl om en linie i dato.js - som i denne version absolut ikke er en
js-fil men noget der faktisk ligner en 404 fejlmeddelelse i XHTML (og det er
doctypen FF beklager sig over - den hører jo ikke til i js).

3
dernæst en fejl "urchinTracker is not defined"



Jeg tror faktisk ikke, /blablabla opfattes som en subfolder - du skulle så
få en 404, da folderen ikke eksisterer, uanset hvilken slags fil der er tale
om.
Jeg tror /blablabla opfattes som en parameter.
Og du skal nok studere din SSI for at finde problemet.
SSI er noget CGI-noget, som for en stor del skrives i Perl.
For mig ser det ud somom der er noget i din fil der får "SSI parseren" til
at gøre noget forkert.
Har selv en gang i tidernes morgen - lidt senere måske - brugt SSI og Perl,
og det fungerede fint.
Men jeg tror ikke det kan svare sig i dag.
Der er ikke noget du kan med SSI, som du ikke kan med i hvert fald PHP (og
formentlig også ASP) i stedet, og måske ville det være en ide til
overvejelse.



Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger skrev:

>
> Hvis det kan være til nogen hjælp...
> I FF får jeg 3 fejl, hvis jeg prøver at åbne den sidste - altså den med
> tilføjelsen der ikke hører til.
>
> 1
> Stilarket http://www.lille-web.dk/sider/404.html blev ikke indlæst, fordi
> dets MIME type, "text/html", ikke er "text/css".
> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla
> Line 0
>
> 2
> en fejl om en linie i dato.js - som i denne version absolut ikke er en
> js-fil men noget der faktisk ligner en 404 fejlmeddelelse i XHTML (og det er
> doctypen FF beklager sig over - den hører jo ikke til i js).
>
> 3
> dernæst en fejl "urchinTracker is not defined"
>
>
Sjovt de fejl får jeg ikke i FF - faktisk kan jeg validere siden hos W3C

>
> Jeg tror faktisk ikke, /blablabla opfattes som en subfolder - du skulle så
> få en 404, da folderen ikke eksisterer, uanset hvilken slags fil der er tale
> om.
> Jeg tror /blablabla opfattes som en parameter.
> Og du skal nok studere din SSI for at finde problemet.
> SSI er noget CGI-noget, som for en stor del skrives i Perl.
> For mig ser det ud somom der er noget i din fil der får "SSI parseren" til
> at gøre noget forkert.

Men selv når jeg fjerner alt der behøver SSI - en fil der kun indeholder
<p> en lille test</p> og giver filen shtml som endelse sker det samme.
Døber jeg den html sker det ikke

> Har selv en gang i tidernes morgen - lidt senere måske - brugt SSI og Perl,
> og det fungerede fint.
> Men jeg tror ikke det kan svare sig i dag.
> Der er ikke noget du kan med SSI, som du ikke kan med i hvert fald PHP (og
> formentlig også ASP) i stedet, og måske ville det være en ide til
> overvejelse.
>

Den er jeg med på men nu har Google fundet disse sider. Ok det kan
klares i min htaccess fil men, men
>
>
> Birger
> -----
> http://bbsorensen.dk
> http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
> opdatering.
>
>

C

---

"Morten P. Andersen" <info@lille-web.dk> skrev i en meddelelse
news:7dd35$47c078dc$5293ecbc$739@news.arrownet.dk...
> Birger skrev:
>
>>
>> Hvis det kan være til nogen hjælp...
>> I FF får jeg 3 fejl, hvis jeg prøver at åbne den sidste - altså den med
>> tilføjelsen der ikke hører til.
>>
>> 1
>> Stilarket http://www.lille-web.dk/sider/404.html blev ikke indlæst, fordi
>> dets MIME type, "text/html", ikke er "text/css".
>> http://www.lille-web.dk/sider/hjemmeside-ydelser.shtml/blablabla
>> Line 0
>>
>> 2
>> en fejl om en linie i dato.js - som i denne version absolut ikke er en
>> js-fil men noget der faktisk ligner en 404 fejlmeddelelse i XHTML (og det
>> er doctypen FF beklager sig over - den hører jo ikke til i js).
>>
>> 3
>> dernæst en fejl "urchinTracker is not defined"
>>
>>
> Sjovt de fejl får jeg ikke i FF - faktisk kan jeg validere siden hos W3C
>
>>
>> Jeg tror faktisk ikke, /blablabla opfattes som en subfolder - du skulle
>> så få en 404, da folderen ikke eksisterer, uanset hvilken slags fil der
>> er tale om.
>> Jeg tror /blablabla opfattes som en parameter.
>> Og du skal nok studere din SSI for at finde problemet.
>> SSI er noget CGI-noget, som for en stor del skrives i Perl.
>> For mig ser det ud somom der er noget i din fil der får "SSI parseren"
>> til at gøre noget forkert.
>
> Men selv når jeg fjerner alt der behøver SSI - en fil der kun indeholder
> <p> en lille test</p> og giver filen shtml som endelse sker det samme.
> Døber jeg den html sker det ikke
>
>> Har selv en gang i tidernes morgen - lidt senere måske - brugt SSI og
>> Perl, og det fungerede fint.
>> Men jeg tror ikke det kan svare sig i dag.
>> Der er ikke noget du kan med SSI, som du ikke kan med i hvert fald PHP
>> (og formentlig også ASP) i stedet, og måske ville det være en ide til
>> overvejelse.
>>
>
> Den er jeg med på men nu har Google fundet disse sider. Ok det kan klares
> i min htaccess fil men, men
>>
>>


FF med Firebug gav mig fejlene...

SSI - Server Side Includes - kører en parser på din fil, inden den sendes
videre, derfor skal den have en anderledes extension (shtml, phtml - og vist
et par andre er tilladte).
Og det må jo være der, der detekteres noget forkert, hvis det også sker med
en fil uden indhold.

Det kan også se ud somom, der er noget forkert med eller i din 404 - du har
en tilpasset?


Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger skrev:

>
>
> FF med Firebug gav mig fejlene...
>
> SSI - Server Side Includes - kører en parser på din fil, inden den sendes
> videre, derfor skal den have en anderledes extension (shtml, phtml - og vist
> et par andre er tilladte).
> Og det må jo være der, der detekteres noget forkert, hvis det også sker med
> en fil uden indhold.
>
> Det kan også se ud somom, der er noget forkert med eller i din 404 - du har
> en tilpasset?
>
>
> Birger
> -----
> http://bbsorensen.dk
> http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
> opdatering.
>
>
Har du en ide til hvad jeg skal gøre?

---

"Morten P. Andersen" <info@lille-web.dk> skrev i en meddelelse
news:e0b8b$47c08370$5293ecbc$17597@news.arrownet.dk...
> Har du en ide til hvad jeg skal gøre?

Ikke umiddelbart.
Jeg har ingen shtml filer, jeg kan prøve med selv.
Men hvis jeg kalder en ikke eksisterende shtml - med eller uden ekstra's -
får jeg den helt almindelige 404 (one.com).

Hvad bruger du SSI til?

Så vidt jeg kan forstå fra diskussionen i PHP-NG, er denne opførsel
almindelig for apache.
Hvis det er rigtigt, er den eneste måde du kan undgå den på, at undgå SSI..


Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger skrev:

> den eneste måde du kan undgå den på, at undgå
> SSI..

Nej, ssi er vejen frem. Hvorfor skal rette rette menuen
på 150 sider, når jeg kan nøjes med at rette den i én
fil?

Jeg har brugt ssi i mange sammenhænge gennem
mange år, på mange forskellige servere - helt uden
problemer.

Morten bør undersøge om det er shtml-parametreren
det går galt med, prøv at lave en fil med .asp til
efternavn, og brug:

<!--#include file="menu.inc"-->

eller i php:

<? include("menu.inc"); ?>

.... bare for at se om det opfører sig anderledes.

--
Allan Vebel
http://html-faq.dk
http://vebel.dk

---

Allan Vebel skrev:
> Birger skrev:
>
>> den eneste måde du kan undgå den på, at undgå
>> SSI..
>
> Nej, ssi er vejen frem. Hvorfor skal rette rette menuen
> på 150 sider, når jeg kan nøjes med at rette den i én
> fil?
>
> Jeg har brugt ssi i mange sammenhænge gennem
> mange år, på mange forskellige servere - helt uden
> problemer.
>
> Morten bør undersøge om det er shtml-parametreren
> det går galt med, prøv at lave en fil med .asp til
> efternavn, og brug:
>
> <!--#include file="menu.inc"-->
>
> eller i php:
>
> <? include("menu.inc"); ?>
>
> ... bare for at se om det opfører sig anderledes.
>

Hvad er det for shtml-parametreren jeg kan lave forkert. Jeg mener jeg
har jo prøvet at fjerne alt på webhotellet - lavet en side kun med
<head> <body> og <p> en lilletest</p>
Alle andre filer var slettet på domænet.
shtml filen gjorde det samme .... altså det forkerte! hvorimod en
tilsvarende html fil gjorde det rigtigt.

På en en tilsvarende server (også One.com) men altså med et andet domæne
virker alt som det skal!

HJÆLP?????

---

Allan Vebel skrev:

>
> Nej, ssi er vejen frem. Hvorfor skal rette rette menuen
> på 150 sider, når jeg kan nøjes med at rette den i én
> fil?
>
> Jeg har brugt ssi i mange sammenhænge gennem
> mange år, på mange forskellige servere - helt uden
> problemer.
>
> Morten bør undersøge om det er shtml-parametreren
> det går galt med, prøv at lave en fil med .asp til
> efternavn, og brug:
>
> <!--#include file="menu.inc"-->
>
> eller i php:
>
> <? include("menu.inc"); ?>
>
> ... bare for at se om det opfører sig anderledes.
>

Denne fil smed jeg på:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>test HTML</title>


</head>

<body>
<p>test HTML</p>
</body>
</html>

jeg kaldte den test.php (ja jeg ved godt at at der i selve koden står
test HTML!)
Men altså men test.php var problemet det samme?

---

"Allan Vebel" <spam@do.not> skrev i en meddelelse
news:47c0956b$0$90275$14726298@news.sunsite.dk...
> Birger skrev:
>
>> den eneste måde du kan undgå den på, at undgå
>> SSI..
>
> Nej, ssi er vejen frem. Hvorfor skal rette rette menuen
> på 150 sider, når jeg kan nøjes med at rette den i én
> fil?
>
> Jeg har brugt ssi i mange sammenhænge gennem
> mange år, på mange forskellige servere - helt uden
> problemer.
>
> Morten bør undersøge om det er shtml-parametreren
> det går galt med, prøv at lave en fil med .asp til
> efternavn, og brug:
>
> <!--#include file="menu.inc"-->
>
> eller i php:
>
> <? include("menu.inc"); ?>
>
> ... bare for at se om det opfører sig anderledes.
>


Hverken PHP eller ASP er SSI.
en fil kan ikke have 2 extensions.

Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger wrote:

>> med .asp til
>> efternavn, og brug:
>>
>> <!--#include file="menu.inc"-->
>>
>> eller i php:
>>
>> <? include("menu.inc"); ?>

> Hverken PHP eller ASP er SSI.
> en fil kan ikke have 2 extensions.

Er vi nu ikke ude i en strid om kejserindens skæg? SSI betyder 'ServerSide
Include' og både i asp og i php kan man serverside inkludere
enkeltkomponenter, der tilsammen udgør en komplet hjemmeside.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk/ - http://ginnerskov.dk/
http://html-faq.dk

---

"Erik Ginnerskov" <erik.ginnerskov@live.dk> skrev i en meddelelse
news:47c1a4c9$0$90271$14726298@news.sunsite.dk...
> Birger wrote:
>
>>> med .asp til
>>> efternavn, og brug:
>>>
>>> <!--#include file="menu.inc"-->
>>>
>>> eller i php:
>>>
>>> <? include("menu.inc"); ?>
>
>> Hverken PHP eller ASP er SSI.
>> en fil kan ikke have 2 extensions.
>
> Er vi nu ikke ude i en strid om kejserindens skæg? SSI betyder 'ServerSide
> Include' og både i asp og i php kan man serverside inkludere
> enkeltkomponenter, der tilsammen udgør en komplet hjemmeside.
>


SSI anvender en separat parser - altså ikke den samme som PHP eller ASP.
Der kan være - er helt åbenlyst - stor forskel på hvordan de ter sig i den
givne situation.
Derfor er det ikke et strid om hverken det ene eller det andet, men en
konstatering af at der er forskel på SSI, PHP og ASP.

Man kan SSI'e PHP filer, formentlig også ASP filer.
include i PHP har ikke noget med SSI at gøre.
Kender ikke til ASP - efter hvad du skrev er ASP syntaksen nøjagtigt den
samme som i SSI, så der anvendes måske samme parser - tror det dog ikke.

Har tidlige sagt at jeg mener den eneste løsning til at blive af med disse
"skyggesider", er at gå over til PHP, evt. ASP, hvor præcis det samme kan
opnås, som i SSI - og IMHO nemmere og mere overskueligt.

Har også spurgt efter hvad det er der gør det nødvendigt at bruge SSI - men
har vist ikke fået svar på det.

SSI bruger HTML kommentarer til at includere output fra andre filer.
Hvis der ikke anvendes SSI, er det en skidt idé at give filerne extension
shtml.


Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

On Sun, 24 Feb 2008 23:52:26 +0100, "Birger" <sdc@bbsorensen.com> wrote:

>>>> <!--#include file="menu.inc"-->
<snip>
>SSI anvender en separat parser - altså ikke den samme som PHP eller ASP.
>Der kan være - er helt åbenlyst - stor forskel på hvordan de ter sig i den
>givne situation.
>Derfor er det ikke et strid om hverken det ene eller det andet, men en
>konstatering af at der er forskel på SSI, PHP og ASP.

Jeps.

>Man kan SSI'e PHP filer, formentlig også ASP filer.

Hmmm ... man får ikke noget godt ud af at SSI en PHP-fil i en ASP-fil,
hvis den indeholder PHP-kode.
SSI (som #include - ved ikke lige med de andre SSI-funktioner) tager
blot den inkludere fil og "limer" den ind i den fil, den inkluderes fra.

Så det er *indholdet* af filen og ikke dens funktion eller ekstension,
der er interessant. Ekstensionen kan være hvad som helst for den
inkluderede fil (men ikke for den inkluderende).

>include i PHP har ikke noget med SSI at gøre.

Nemlig.

>Kender ikke til ASP - efter hvad du skrev er ASP syntaksen nøjagtigt den
>samme som i SSI, så der anvendes måske samme parser - tror det dog ikke.

Som jeg forstår det, er SSI (eller anden include) *ikke* inkluderet i
ASP. ASP sites anvender derimod "rigtig" SSI. Og derfor samme syntaks
som SSI og SSI parser.

<snip>
>SSI bruger HTML kommentarer til at includere output fra andre filer.
>Hvis der ikke anvendes SSI, er det en skidt idé at give filerne extension
>shtml.

Det er vist (funktionsmæssigt) lige meget, da selve den inkluderede fil
jo ikke parses separat af serveren, men kun som en del af den
inkluderende fil - og derfor kan hedde hvad som helst.
Men det sender selvfølgelig et forkert signal, så jeg ville også bruge
en anden ekstension.

Typisk bruger jeg "filnavn.inc.asp" til inkluderede filer i ASP. Det har
den fordel, at jeg dels ved, at de er beregnet til include (pga. .inc)
og at kilden ikke kan læses direkte fra en browser (pga. .asp).


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

"Jørn Andersen" <jorn@jorna.dk> skrev i en meddelelse
news:qml4s3dqu5r5pm4ntnf6840cc58rov09ne@4ax.com...
8X
>>Man kan SSI'e PHP filer, formentlig også ASP filer.
>
> Hmmm ... man får ikke noget godt ud af at SSI en PHP-fil i en ASP-fil,
> hvis den indeholder PHP-kode.
> SSI (som #include - ved ikke lige med de andre SSI-funktioner) tager
> blot den inkludere fil og "limer" den ind i den fil, den inkluderes fra.
>
8X


Mente nu, at jeg mener man kan SSI'e både PHP og ASP filer :

<--#exec cgi="menu.php" --> eller
<--#exec cgi="menu.asp" -->


Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger skrev:

> Mente nu, at jeg mener man kan SSI'e både PHP og ASP filer :

Kan og kan. Man får ikke noget brugbart ud af det medmindre man
laver det for pjat og bare omdøber .htm-filer til .php og .asp.

Hvis man i samme samlede fil har både ASP og PHP, så vil kun en
af delene virke, og det andet vil fremstå som tekst eller udløse
fejlmeddelelser i hobetal.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:gr85s39tbcc4ol4gbv6g123voacuosorqv@4ax.com...
> Birger skrev:
>
>> Mente nu, at jeg mener man kan SSI'e både PHP og ASP filer :
>
> Kan og kan. Man får ikke noget brugbart ud af det medmindre man
> laver det for pjat og bare omdøber .htm-filer til .php og .asp.
>
> Hvis man i samme samlede fil har både ASP og PHP, så vil kun en
> af delene virke, og det andet vil fremstå som tekst eller udløse
> fejlmeddelelser i hobetal.
>


Nu er det længe siden jeg har arbejdet med CGI...
Men jeg mener at exec cmd og cgi faktisk kører de programmer man beder om -
hvis man cgi eller exec en .php eller .asp, skal man således få resultatet
af det kørte tilhørende script, og ikke kildekoden.

Hvis man blot bruger #include, får man naturligvis kun kildekoden...
Men SSI er faktisk meget mere ende include...

Birger
-----
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt. Daglig
opdatering.

---

Birger wrote:

> efter hvad du skrev er ASP syntaksen nøjagtigt
> den samme som i SSI,

Det var nu ikke lige mig, der skrev det, man la' nu det ligge. Det er jo
rigtigt.

> Har tidlige sagt at jeg mener den eneste løsning til at blive af med
> disse "skyggesider", er at gå over til PHP,

Det tror jeg ikke du skal regne med. Jeg har selv testet på en side, der
hedder .php og ligger på en apache-server (unoeuro.com). Sætter jeg en /
efter filnavnet i adresselinjen, får jeg samme problem: Siden vises uden
css-formatering. Det hjælper endda ikke at sætte en / foran stien til css i
headerens kald til css.

Jeg for mit vedkommende vil begrænse mig til at sige, at der skal _absolut
ikke_ sættes en / efter filnavnet hverken i adresselinjen eller i et link.
Det er fejlformatering af filadressen og så beder man selv om problemet.
Foran filnavnet kan man sætte det antal /'er, som stien til filen betinger,
men altså ikke nogen efter.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk/ - http://ginnerskov.dk/
http://html-faq.dk

---

Birger skrev:


> Har også spurgt efter hvad det er der gør det nødvendigt at bruge SSI - men
> har vist ikke fået svar på det.
>

Jo mit svar var at nu kender Google og de andre søgemaskiner mine shtml
filer og de ranker meget godt på nogle af min søgeord.
Jeg kan selvfølgelig afhjælpe dette med min htaccess fil men det ville
være bedst hvis jeg bare kan fortsætte med shtml

---

---

---

On 23 Feb., 22:51, "Allan Vebel" <s...@do.not> wrote:
> ... bare for at se om det opfører sig anderledes.

Jeg fandt den her side på nettet, hvor problemet med trailing slash i
SSI omtales:
http://www.jlk.net/apache/colophon_ssi.shtml

<citat>
SSI Gotchas!

Trailing Slash .../
Watch out for a trailing slash /. If you add a trailing slash to the
url for a page, you will break SSI. i.e. The reference for this page
is:
http://www.jlk.net/apache/colophon_ssi.shtml

but if you add a trailing slash
http://www.jlk.net/apache/colophon_ssi.shtml/

all hell will break loose with SSIs.
</citat>

Så det lader til, at det er en kendt quirk i SSI.

t

---

Tomasz Otap skrev:

> Så det lader til, at det er en kendt quirk i SSI.

Ja, men jeg har dog aldrig set at en slash alligevel
viser siden, bare uden css, som i Mortens tilfælde.

Det er derfor jeg vil have ham til at prøve noget
andet.

Jeg brugte shtml på get2net.dk for 10 år siden,
fordi de ikke understøttede andet, og det kørte
altså ikke godt - det gør det fortsat ikke, der.

På et webhotel med asp og php var er ingen
problemer med at få ssi til at køre.

--
Allan Vebel
http://html-faq.dk
http://vebel.dk

---

Tomasz Otap skrev:
> On 23 Feb., 22:51, "Allan Vebel" <s...@do.not> wrote:
>> ... bare for at se om det opfører sig anderledes.
>
> Jeg fandt den her side på nettet, hvor problemet med trailing slash i
> SSI omtales:
> http://www.jlk.net/apache/colophon_ssi.shtml
>
> <citat>
> SSI Gotchas!
>
> Trailing Slash .../
> Watch out for a trailing slash /. If you add a trailing slash to the
> url for a page, you will break SSI. i.e. The reference for this page
> is:
> http://www.jlk.net/apache/colophon_ssi.shtml
>
> but if you add a trailing slash
> http://www.jlk.net/apache/colophon_ssi.shtml/
>
> all hell will break loose with SSIs.
> </citat>
>
> Så det lader til, at det er en kendt quirk i SSI.
>
> t
Det kan være du har ret. Fandt denne side ironisk nok om SSI
http://www.students.mines.edu/examples/ssi.shtml

jeg læste men forstod ikke så meget!

Så prøvede jeg lige denne URL
http://www.students.mines.edu/examples/ssi.shtml
http://www.students.mines.edu/examples/ssi.shtml/dfkjgnldkgnksdgjnjsdfn

BINGO - samme problem

---