/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
Variablen PHP_SELF
Fra : MiG


Dato : 17-07-01 07:22

Er der andre som har oplevet at variablen PHP_SELF ikke virker med PHP
4.0.6???



 
 
Christian Joergensen (17-07-2001)
Kommentar
Fra : Christian Joergensen


Dato : 17-07-01 07:36

MiG <clark@cool.dk> wrote:

> Er der andre som har oplevet at variablen PHP_SELF ikke virker med PHP
> 4.0.6???

Den virker fint her på Debian med Apache 1.3.20

--
Christian Jørgensen | "Ford, you're turning into a penguin"
http://www.razor.dk | "Stop it"

Steven Bergstedt (17-07-2001)
Kommentar
Fra : Steven Bergstedt


Dato : 17-07-01 17:00

Christian Joergensen wrote in <2615692.MWURcNyiUU@flaf>:

> Den virker fint her på Debian med Apache 1.3.20
Ja men ikke hvis du browser med Opera for mit vedkommende.

--
/* Best regards
Steven Bergstedt
"Imagination is more important than knowledge."
by AE */

Christian Joergensen (18-07-2001)
Kommentar
Fra : Christian Joergensen


Dato : 18-07-01 09:46

Steven Bergstedt <mail@linuxguru.dk> wrote:

>> Den virker fint her på Debian med Apache 1.3.20

> Ja men ikke hvis du browser med Opera for mit vedkommende.

Browseren har ikke noget at gøre med indholdet af variablen.

--
Christian Jørgensen | "Ford, you're turning into a penguin"
http://www.razor.dk | "Stop it"

Steven Bergstedt (18-07-2001)
Kommentar
Fra : Steven Bergstedt


Dato : 18-07-01 09:54

Christian Joergensen <mail@phpguru.dk> wrote in news:Xns90E26CAB0B944l33t@
212.54.64.134:

>> Ja men ikke hvis du browser med Opera for mit vedkommende.
>
> Browseren har ikke noget at gøre med indholdet af variablen.
Jep. Jeg ved godt at det ikke har noget med browseren at gøre, men hvordan
vil du forklare, at Opera ikke kan håndtere php_self når andre så som:
Mozilla og Konq ikke har noget problem med det? Kunne det mon tænkes at der
er et mindre lag i den eller er jeg den enester der har dette problem med
Opera?;)

--
/* Best regards
Steven Bergstedt
"Imagination is more important than knowledge."
by AE */

N/A (18-07-2001)
Kommentar
Fra : N/A


Dato : 18-07-01 10:29



Thomas Jensen - pil.~ (18-07-2001)
Kommentar
Fra : Thomas Jensen - pil.~


Dato : 18-07-01 10:29

On Wed, 18 Jul 2001 11:17:50 +0200, Steven Bergstedt
<mail@linuxguru.dk> wrote:

>> Jep. Jeg ved godt at det ikke har noget med browseren at gøre, men hvordan
>> vil du forklare, at Opera ikke kan håndtere php_self når andre så som:
>> Mozilla og Konq ikke har noget problem med det? Kunne det mon tænkes at
>> der er et mindre lag i den eller er jeg den enester der har dette problem
>> med Opera?;)
>Sikken en gang BEEP! Opera fejler ingen ting overhoved! Bare mig der har
>fede fingere og ikke kan ramme de rigtige taster. Jeg beklager meget, men
>ovenstående var en fejl 40.

<ud af en tangent>
iøvrigt havde vi fornylig en situation hvor vi var lige v. at tro at
forsk. browsere behandlere php forkert.

En kunde meldte at en 100% serverparsed side ikke virkede i en given
browser til mac. Vores umiddelbare respons var noget ala "vås".

Han var dog så vedholdende at vi til sidst måtte sætte os til en mac
for selv at konstatere problemet... og sandt nok, siden virkede ikke
på maccen.

Vi var lige v. at blive forvirrede indtil vi fandt ud at kunden i
samme directory som den pågældende index.php havde smidt en statisk
index.html, og den pågældende browser yderst fejlagtigt prioriterede
extensions i en anden rækkefølge end serverens konfiguration (.html
førend .php)

Det er klart at mickeybrowsere under mac skal have lov til at ignorere
serveropsætninger, for den ved jo bedst.... NOT
</ud af en tangent>
--
vh
Thomas Jensen, http://pil.dk/

Peter Brodersen (18-07-2001)
Kommentar
Fra : Peter Brodersen


Dato : 18-07-01 15:16

On Wed, 18 Jul 2001 11:28:51 +0200, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>Vi var lige v. at blive forvirrede indtil vi fandt ud at kunden i
>samme directory som den pågældende index.php havde smidt en statisk
>index.html, og den pågældende browser yderst fejlagtigt prioriterede
>extensions i en anden rækkefølge end serverens konfiguration (.html
>førend .php)

WTF? Det lyder altså tilsvarende som "vås".

Er der browsere, der rent faktisk selv skulle gætte på filnavne for et
katalog? Det er ellers noget, browserne altid har holdt sig væk fra.

Idet der burde være hit på katalog-requestet (altså GET på fx "/"),
burde browseren ikke komme i en situation, hvor der skulle vælges.
Ikke medmindre, I havde hældt nogle interessante Apache-moduler på,
der gav brugeren mulighed for at vælge eller lignende.

Hvilken browser var der tale om?

--
- Pede
Professionel nørd

Thomas Jensen - pil.~ (18-07-2001)
Kommentar
Fra : Thomas Jensen - pil.~


Dato : 18-07-01 15:31

On Wed, 18 Jul 2001 16:16:03 +0200, Peter Brodersen
<professionel@nerd.dk> wrote:

>>Vi var lige v. at blive forvirrede indtil vi fandt ud at kunden i
>>samme directory som den pågældende index.php havde smidt en statisk
>>index.html, og den pågældende browser yderst fejlagtigt prioriterede
>>extensions i en anden rækkefølge end serverens konfiguration (.html
>>førend .php)
>
>WTF? Det lyder altså tilsvarende som "vås".

Jeg er villig til at indgå væddemål

Ikke bare dumme jeg, men også mine mere fagligt kompetente kolleger
kan bevidne.

>Er der browsere, der rent faktisk selv skulle gætte på filnavne for et
>katalog?

øjensynligt

>Det er ellers noget, browserne altid har holdt sig væk fra.

Vi kan vi snart forvente en patentansøgning fra mickey. Det er vel
nærmest revolutionerende hvad de kan.

>Idet der burde være hit på katalog-requestet (altså GET på fx "/"),
>burde browseren ikke komme i en situation, hvor der skulle vælges.
>Ikke medmindre, I havde hældt nogle interessante Apache-moduler på,
>der gav brugeren mulighed for at vælge eller lignende.

det har vi ikke.

>Hvilken browser var der tale om?

Med mindre den pågældende maskine er blevet opgraderet siden[1], var
det en msie 5.0 på en imac.

[1] ved det ikke... det er ikke vores maskine.

--
vh
Thomas Jensen, http://pil.dk/

Peter Brodersen (18-07-2001)
Kommentar
Fra : Peter Brodersen


Dato : 18-07-01 15:50

On Wed, 18 Jul 2001 16:31:21 +0200, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>>WTF? Det lyder altså tilsvarende som "vås".
>Jeg er villig til at indgå væddemål

Nu har jeg selv vundet flere kasser øl ved selv at foreslå at indgå
væddemål om hvorvidt, jeg kunne/vidste nogle ting, så jeg har da
erfaring nok til ikke at indgå væddemål, når dem, der skal bevise
noget, også er dem, der foreslår væddemålet i første omgang

>>Hvilken browser var der tale om?
>Med mindre den pågældende maskine er blevet opgraderet siden[1], var
>det en msie 5.0 på en imac.
>
>[1] ved det ikke... det er ikke vores maskine.

Vildt - det tror jeg, jeg må teste en sjat med. En sådan opførsel kan
jeg slet ikke se giver nogen form for sammenhæng...

Det, der undrer mig, er bare at browseren i første omgang skulle
requeste "/index.html" i stedet for fx "/". Som en del af
vedligeholdelse på diverse sites, modtager jeg nu og da 404-rapporter,
og jeg har ikke lige faldet over noget, der mindede om det.

Hvad sagde jeres logs?

(til gengæld har jeg flere gange oplevet MSIE vise en forkert URL i
adresselinien - det sker nogle gange, hvis der redirectes, så retter
MSIE ikke nødvendigvis adresselinien til, heller ikke ved F5/reload)


--
- Pede
Professionel nørd

Thomas Jensen - pil.~ (18-07-2001)
Kommentar
Fra : Thomas Jensen - pil.~


Dato : 18-07-01 15:56

On Wed, 18 Jul 2001 16:50:14 +0200, Peter Brodersen
<professionel@nerd.dk> wrote:

>Vildt - det tror jeg, jeg må teste en sjat med. En sådan opførsel kan
>jeg slet ikke se giver nogen form for sammenhæng...

de var vel fulde... for år tilbage var jeg semi-mac-bruger, og så hvad
de kunne gøre v. en på win-platformen velfungerende word-version.

>Hvad sagde jeres logs?

jeg må m. skam tilstå at dertil nåede vi ikke... vi bad kunden slette
sin index.html, og så kom vi hurtigt videre i vores liv.

Hvis en faktureringsadresse eller lign. postes sender vi gerne en
konsulent som kan fordybe sig yderligere i sagens akter... alternativt
vil jeg måske senere i aften prøve at reproducere.


--
vh
Thomas Jensen, http://pil.dk/

Thomas Jensen - pil.~ (18-07-2001)
Kommentar
Fra : Thomas Jensen - pil.~


Dato : 18-07-01 21:11

On Wed, 18 Jul 2001 16:56:28 +0200, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>Hvis en faktureringsadresse eller lign. postes sender vi gerne en
>konsulent som kan fordybe sig yderligere i sagens akter... alternativt
>vil jeg måske senere i aften prøve at reproducere.

jeg forsøgte mig lige[1] igen, men kunne naturligvis ikke genskabe m.
den installerede msie 5.0 i al fald.

[1] http://tjpil.flaf.dk:8080/mac/
--
vh
Thomas Jensen, http://pil.dk/

Johan (19-07-2001)
Kommentar
Fra : Johan


Dato : 19-07-01 09:37

Midt i denne spændende diskussion vil jeg egentlig lige bryde ind omkring
platforms afhængighed vs. PHP.

Der er en ting der undrer mig når man fremkalder en phpinfo();

På en Mac får man følgende variable frem:
HTTP_SERVER_VARS['HTTP_UA_OS'] samt HTTP_UA_CPU mf.
Men de kommer ikke frem når man kører phpinfo(); fra mim Win2k eller Linux
Redhat 7.0

Nogle der kan forklare mig hvorfor det sker?? Kan den ikke finde OS ved Win
og Linux maskiner?!?

Mvh

Johan



Christian Joergensen (19-07-2001)
Kommentar
Fra : Christian Joergensen


Dato : 19-07-01 18:15

Johan <tcr480@ofir.dk> wrote:

> Nogle der kan forklare mig hvorfor det sker?? Kan den ikke finde OS ved
> Win og Linux maskiner?!?

Jeg ville nok kigge i konstanten PHP_OS.

ex.

<?=PHP_OS?>

--
Christian Jørgensen | "Ford, you're turning into a penguin"
http://www.razor.dk | "Stop it"

Johan (20-07-2001)
Kommentar
Fra : Johan


Dato : 20-07-01 09:34

> > Nogle der kan forklare mig hvorfor det sker?? Kan den ikke finde OS ved
> > Win og Linux maskiner?!?
>
> Jeg ville nok kigge i konstanten PHP_OS.
>
> ex.
>
> <?=PHP_OS?>

Ja, men det undrer mig bare at der er forskel på phpinfo(); når man kigger
fra en mac i forhold til en PC. Ledte egentlig ikke efter en løsning, men
undrede mig bare. Og det kunne være det var en god grund til hvorfor det er
således?

mvh

Johan



Christian Schmidt (22-07-2001)
Kommentar
Fra : Christian Schmidt


Dato : 22-07-01 12:23

Johan wrote:
>
> Der er en ting der undrer mig når man fremkalder en phpinfo();
>
> På en Mac får man følgende variable frem:
> HTTP_SERVER_VARS['HTTP_UA_OS'] samt HTTP_UA_CPU mf.
> Men de kommer ikke frem når man kører phpinfo(); fra mim Win2k eller Linux
> Redhat 7.0
>
> Nogle der kan forklare mig hvorfor det sker?? Kan den ikke finde OS ved Win
> og Linux maskiner?!?

Alle server-variable, der starter med HTTP_ stammer fra browseren selv.

Browserens HTTP-forespørgsel ser således ud i retning af flg.:

GET /phpinfo.php HTTP/1.1
Host: www.domæne.dk
Accept: image/gif, image/jpeg, image/png, */*
Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding: gzip
UA-OS: Mac


Browsere (og proxyservere) kan således opfinde sine egne
(volapyk-)variable, som vil være tilgængelige for PHP.


Christian

Peter Brodersen (22-07-2001)
Kommentar
Fra : Peter Brodersen


Dato : 22-07-01 18:47

On Sun, 22 Jul 2001 13:23:14 +0200, Christian Schmidt
<christian@schmidt.net> wrote:

>Alle server-variable, der starter med HTTP_ stammer fra browseren selv.

Det gælder nu ikke HTTP_SERVER_VARS og HTTP_ENV_VARS (som en del af
track-vars)...


--
- Pede
Professionel nørd

Christian Schmidt (22-07-2001)
Kommentar
Fra : Christian Schmidt


Dato : 22-07-01 20:28

Peter Brodersen wrote:
>
> >Alle server-variable, der starter med HTTP_ stammer fra browseren selv.
>
> Det gælder nu ikke HTTP_SERVER_VARS og HTTP_ENV_VARS (som en del af
> track-vars)...

Korrekt - og heller ikke HTTP_COOKIE_VARS.

Det jeg mente var vist, at de enkelte headerlinier i brugerens
HTTP-forespørgsel er afspejlet i de elementer i arrayet
HTTP_SERVER_VARS, hvis navn starter med HTTP_, dvs.
HTTP_SERVER_VARS['HTTP_xxx'].


Christian

Lars L. Christensen (17-07-2001)
Kommentar
Fra : Lars L. Christensen


Dato : 17-07-01 16:04

"MiG" <clark@cool.dk> skrev i en meddelelse news:9j0lmv$1g9b$1@news.cybercity.dk...
> Er der andre som har oplevet at variablen PHP_SELF ikke virker med PHP
> 4.0.6???

Prøv eventuelt at bruge: $HTTP_SERVER_VARS['PHP_SELF']


Til gengæld har jeg problemer med, at den ikke virker på sider der ses med en Netscape Navigator...
Meeeget underligt...

mvh
Lars



Søg
Reklame
Statistik
Spørgsmål : 177554
Tips : 31968
Nyheder : 719565
Indlæg : 6408852
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste