Home » Php » .php file extension in browsers – PHP

.php file extension in browsers – PHP

Posted by: admin February 23, 2020 Leave a comment

Q(Question):

I have recently installed php, apache on windows xp.

I have wrote a simple test file — test.php

<?php

echo "hello world"

?>

When I plugin the http://localhost/test.php in IE it works fine and
when I plugin the same in OPERA it gives me a file download box.

when I type http://localhost/test instead of http://localhost/test.php
in IE the script still runs fine in the browser.

What am I doing wrong here.

Appreciate your help

A(Answer):

al*******@gmail.com wrote:

I have recently installed php, apache on windows xp.

I have wrote a simple test file — test.php

<?php

echo "hello world"

?>

When I plugin the http://localhost/test.php in IE it works fine and
when I plugin the same in OPERA it gives me a file download box.

when I type http://localhost/test instead of http://localhost/test.php
in IE the script still runs fine in the browser.

What am I doing wrong here.

Appreciate your help

I’m not sure what you are doing wrong, but since PHP is entirely
processed by the server, the browser never sees it.
Since what you say Opera shows you appears to be nothing whatever to do
with your script, I think your Opera must be looking at somewhere else
entirely. Do you have an odd proxy set up?

Colin

A(Answer):

Not true.

Although the PHP is parsed through the server, a file with the
(generally) ‘php’ extension is sent to the client with HTML.

IE understands that the .php extension contains HTML markup (as
processed by the server).

By the same token, IE knows that (for instance) .jpg is not going to
look pretty in ASCII so it shows a download box.

Opera believes that PHP files are not viewable and, therefore, is
offering you the chance to download it.

A(Answer):

Rationem said the following on 03/10/2005 23:45:

Not true.

Although the PHP is parsed through the server, a file with the
(generally) ‘php’ extension is sent to the client with HTML.

IE understands that the .php extension contains HTML markup (as
processed by the server).

By the same token, IE knows that (for instance) .jpg is not going to
look pretty in ASCII so it shows a download box.

Opera believes that PHP files are not viewable and, therefore, is
offering you the chance to download it.

Well, that’s gibberish…


Oli

A(Answer):

Oli Filth (ca***@olifilth.co.uk) wrote:
: Rationem said the following on 03/10/2005 23:45:
: > Not true.
: >
: > Although the PHP is parsed through the server, a file with the
: > (generally) ‘php’ extension is sent to the client with HTML.
: >
: > IE understands that the .php extension contains HTML markup (as
: > processed by the server).
: >
: > By the same token, IE knows that (for instance) .jpg is not going to
: > look pretty in ASCII so it shows a download box.
: >
: > Opera believes that PHP files are not viewable and, therefore, is
: > offering you the chance to download it.
: >

: Well, that’s gibberish…

That’s not gibberish at all.

And in fact may entirely explain the problem.

If the output of the php script is sent as "content-type: something/odd"
then opera would correctly display a download dialog, whereas explorer
would likely ignore the content-type and use the file extension plus what
it "sees" in the data to guess it is supposed to be text/html and so
display it.

That’s the well known behaviour of IE, and a well known difference between
IE and some other browsers.

Whether that is what is happening here, who knows…?

This programmer available for rent.

A(Answer):

Malcolm Dew-Jones wrote:

If the output of the php script is sent as "content-type: something/odd"
then opera would correctly display a download dialog, whereas explorer
would likely ignore the content-type and use the file extension plus what
it "sees" in the data to guess it is supposed to be text/html and so
display it.

Some clarification: IE will always sniff the content stream for the
file type. It only considers the content-type header when the test
returns inconclusive result (e.g. text/html vs. text/plain). The file
extension doesn’t play a role at all. You can see for yourself by
saving a .txt file with the line "GIF89a is the signature of GIF files"
and retrieving it through IE.

A(Answer):

Have you tried with content-type: something/odd with Opera ??
I won’t affect browsing .php file..

Something wrong other than that

Kerul4u
[ProDesignz]

A(Answer):

al*******@gmail.com wrote:

I have recently installed php, apache on windows xp.

I have wrote a simple test file — test.php

<?php

echo "hello world"

?>

When I plugin the http://localhost/test.php in IE it works fine and
when I plugin the same in OPERA it gives me a file download box.

when I type http://localhost/test instead of http://localhost/test.php
in IE the script still runs fine in the browser.

What am I doing wrong here.

Appreciate your help

In opera 8.5 on windows, select tools -> preferences -> advanced tab ->
downloads. Do you have anything in this list with an extension of ‘php’?
If so, edit it and check the ‘open with opera’ option.

A(Answer):

No there is no .php extension in the opera downloads tab.

The strange thing is opera opens all commercial websites with .php
extension and works fine.

Should I include "content-type info in the begining of every php file ?

A(Answer):

al*******@gmail.com wrote:

No there is no .php extension in the opera downloads tab.

The strange thing is opera opens all commercial websites with .php
extension and works fine.

Should I include "content-type info in the begining of every php file ?

No, no headers should not be required of the php.
This leads me to believe that you have not configured your web server
correctly.
Are you using apache? Have you installed and configured php to work with
your web server?

A(Answer):

al*******@gmail.com wrote:

No there is no .php extension in the opera downloads tab.

The strange thing is opera opens all commercial websites with .php
extension and works fine.

Should I include "content-type info in the begining of every php file ?

Better, sniff the headers and find what Content-type is been
delivered. Possibly, the "default_mimetype" directive in php.ini might
be set to some other values; it should be "text/html"


<?php echo ‘Just another PHP saint’; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

A(Answer):

Carl wrote:

al*******@gmail.com wrote:

No there is no .php extension in the opera downloads tab.

The strange thing is opera opens all commercial websites with .php
extension and works fine.

Should I include "content-type info in the begining of every php file ?

No, no headers should not be required of the php.
This leads me to believe that you have not configured your web server
correctly.
Are you using apache? Have you installed and configured php to work with
your web server?

Please disregard.
I just read the part again about it working in explorer and not opera,
so my last suggestion really shouldn’t apply.

A(Answer):

alamsetti wrote:

When I plugin the http://localhost/test.php in IE it works fine and
when I plugin the same in OPERA it gives me a file download box.

as usual, a URL (preferably of a minimal example) is a must, otherwise
it’s pure guesswork.

Microsoft have documented how IE detects MIME types, and it clearly
conflicts with HTTP (sec. 7.2.1), yet they tout this conflict as a
"feature"! the Redmond boys can really technobabble with the best:

http://msdn.microsoft.com/workshop/n…appendix_a.asp

Opera, I believe, doesn’t have this bug of IE’s.


Jock

A(Answer):

Thanks. This explains a lot. I have written a translation script that
will convert a HTML page to PML (a plaintext format that can be
converted to Palmreader documents). However, as the first HTML tags were
processed, IE kept displaying the results as HTML, despite the header
stating it was text/plain. At some point during development, it got
displayed as text.

John Dunlop wrote:

alamsetti wrote:

When I plugin the http://localhost/test.php in IE it works fine and
when I plugin the same in OPERA it gives me a file download box.

as usual, a URL (preferably of a minimal example) is a must, otherwise
it’s pure guesswork.

Microsoft have documented how IE detects MIME types, and it clearly
conflicts with HTTP (sec. 7.2.1), yet they tout this conflict as a
"feature"! the Redmond boys can really technobabble with the best:

http://msdn.microsoft.com/workshop/n…appendix_a.asp

Opera, I believe, doesn’t have this bug of IE’s.

A(Answer):

Dikkie Dik wrote:

John Dunlop wrote:

http://msdn.microsoft.com/workshop/n…appendix_a.asp
Thanks. This explains a lot.

what, you mean, you understood that?? I salute you. it took me god knows
how many readings just to get the gist of it.
I have written a translation script that will convert a HTML page to PML
(a plaintext format that can be converted to Palmreader documents).
However, as the first HTML tags were processed, IE kept displaying the
results as HTML, despite the header stating it was text/plain.
At some point during development, it got displayed as text.

IE recognises text/plain as an ‘ambiguous’ type (although the doc does
mention an exception, IE6 for XP SP2), so to disambiguate it it scans the
contents (the first 256 bytes) and determines what it thinks should be the
"true" type, and thus overrides your Content-Type header (step 2).

Broken As Designed.


Jock

A(Answer):

John Dunlop (us*********@john.dunlop.name) wrote:
: Dikkie Dik wrote:

: > John Dunlop wrote:
: >
: > > http://msdn.microsoft.com/workshop/n…appendix_a.asp
: >
: > Thanks. This explains a lot.

: what, you mean, you understood that?? I salute you. it took me god knows
: how many readings just to get the gist of it.

: > I have written a translation script that will convert a HTML page to PML
: > (a plaintext format that can be converted to Palmreader documents).
: > However, as the first HTML tags were processed, IE kept displaying the
: > results as HTML, despite the header stating it was text/plain.
: > At some point during development, it got displayed as text.

: IE recognises text/plain as an ‘ambiguous’ type (although the doc does
: mention an exception, IE6 for XP SP2), so to disambiguate it it scans the
: contents (the first 256 bytes) and determines what it thinks should be the
: "true" type, and thus overrides your Content-Type header (step 2).

: Broken As Designed.
Which suggests another work around that be ok in some situations.

Simply insert a blank line at least 256 bytes/characters long at the top
of the text.

This programmer available for rent.