Closed Bug 172478 Opened 23 years ago Closed 23 years ago

phtml pages not shown

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: beanladen, Assigned: asa)

Details

Mozilla 1.2a Linux i686 1. Try to load a webpage of type application/x-httpd-php (I used a local file from a cdrom) ==> popup appears "You have choosen to download blabla etc.pp..." Expected: Simply show page like Netscape 4.x does it with the same file. Seems like there's a missing mime type for that.
dup of bug 163589?
So let me get this straight. You loaded a file whose name ended in what exactly? ".php"? ".phtml"? Which?
yyy.phtml from a file:///xxxx/index.html through a <a href="yyy.phtml">yyy</a> link. Works on Netscape 4.x. Http 1.1/pipelined. Here's the index.html (hope bugzilla will not expand it): <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title>LE-Support</title> </head> <body bgcolor="white" text="black" link="blue" alink="red" vlink="purple"> <center> <h1>LE-Support</h1> <a href="supportdb.phtml"><b>Support DB</b></a><br> <a href="frage.phtml"><b>Neue Frage</b></a><br> </center> </body> </html>
You're talking about "local file from CDROM". How does HTTP come in? If you _are_ loading it over HTTP, what MIME type does the server send? If you're loading it from disk, what does mime.types have to say about ".phtml" files?
No difference if loading over file or http. Both times application/x-httpd-php is delivered. No entry for phtml in personal .mime.types nor .mailcap, but in all system supplied files. And of course everything works ok with Netscape 4.x with exactly the same files/mimes/mailcaps and setup on the same computer with the same user. Must definitely be some problem with the Mozilla supplied mimetypes. Personal profile mimeTypes.rdf is default (empty): <?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:NC="http://home.netscape.com/NC-rdf#"> <Description about="urn:mimetypes"> <NC:MIME-types> <Seq about="urn:mimetypes:root"> </Seq> </NC:MIME-types> </Description> </RDF>
The same problem also occurs when I try to view the attachment given in comment #6 of bug 163589.
> Both times application/x-httpd-php is delivered Which is not a type we know how to handle... and righfully so. This is the type for a PHP source file, not for output of a PHP script. If you're seeing this over HTTP, your PHP script is not sending a content-type header. > Netscape 4.x with exactly the same files/mimes/mailcaps I very much doubt that's the case. For example, Netscape 4.x does not look at /etc/mime.types. We do.
Oh, and the attachment to bug 163589 _is_ labeled as application/x-httpd-php so that's the type bugzilla sends for it. Again, this is not a type Mozilla knows how to render.
Oh, I think there's a misunderstanding ! Netscape DOES show those files ! What I'm saying here is that Mozilla REPORTS that x-http-php has been delivered. What the server actually sends, I don't know. Since Netscape shows the files, and you say it does not understands these files, I suspect that it sends text/html. So Mozilla does a misinterpretation of the content type because of looking into mime.types first and not onto the actual type (at least that's what I logically can derive from the facts).
Ok Ok, there's some complete confusion here. Here is what actually happens: Netscape 4.x tries to show any file when loaded over 'file:///'. Since, if ignoring the script entries, there's some valid html body, I see indeed this html contents, and it looked like the scripts worked (looks like Netscape just ignores the things it does not know). But the sources are exactly what is in the .phtml file. Loading this over 'http://' works exactly the same manner, but only for the first file, since that content actually IS HTTP (!), despite it was named .phtml. All files below that top entry file pop up a 'save as...' dialog with the x-http-phtml content type. And so it does on loading the attachment of 163589. So the only question left here is if Mozilla will interpret x-http-php by itself, which is probably a WONTFIX or even INVALID.
resolved INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.