When I attempt to navigate to the PHP script at http://localhost/project/admin, I expect to see the script results in my web browser.
Instead, I see a dialog box for downloading the file with the message below:
You have chosen to open <filename>, which is a: application/x-httpd-php from: http://localhost
What should Firefox do with this file? Open with... • Save... • etc.
Any idea what is going on?
PHP is not correctly installed on the server or Apache is not using mod_php
In the case of this happening in IIS. I would say that the mimetype is not setup correctly and that the server doesn't know how to handle the extension ".php"
It sounds like an incorrect Content-type header is being sent. This header sets the mime-type for the data the browser receives and, if the browser doesn't have a handler to render that specific mime-type, it will ask to open/save the file instead.
I would start by checking your PHP file for a header() statement and a mis-typed content-type.
Related
I am trying to redirect the user to simply another phtml file when they logout. I am using the function header like so:
header('Location: ../../Site/index.phtml');
exit;
In reality when that runs, the user is greeted if they want the file to be opened and they're not automatically re-directed. Like shown in the image. How can I get them to redirected please without the dialog (automatically). I am running a localhost.
Many thanks
Image of the output
The problem is likely due to the fact that .phtml is a very old PHP file extension (from PHP 2, circa 1997). We're now on PHP 7, and as such, most web servers don't even have logic built in to handle the .phtml extension.
Because your webserver (in this case localhost) doesn't know what to do with the file, it falls back and lets your browser handle it. Because your browser doesn't have an associated default file handler for the extension, it prompts you for an action (assuming a user would be more familiar with a file extension).
The easiest way to resolve this would be to simply switch to the .php extension, as I'm yet to encounter a server that is unable to handle the main PHP extension.
If you are still having issues opening the file, ensure that you specify the type of the file with header("Content-Type: text/html"), which is the default for PHP. This shouldn't be necessary, but will ensure that your browser correctly parses the file as a PHP file.
Hope this helps! :)
When I attempt to navigate to the PHP script at http://localhost/project/admin, I expect to see the script results in my web browser.
Instead, I see a dialog box for downloading the file with the message below:
You have chosen to open <filename>, which is a: application/x-httpd-php from: http://localhost
What should Firefox do with this file? Open with... • Save... • etc.
Any idea what is going on?
PHP is not correctly installed on the server or Apache is not using mod_php
In the case of this happening in IIS. I would say that the mimetype is not setup correctly and that the server doesn't know how to handle the extension ".php"
It sounds like an incorrect Content-type header is being sent. This header sets the mime-type for the data the browser receives and, if the browser doesn't have a handler to render that specific mime-type, it will ask to open/save the file instead.
I would start by checking your PHP file for a header() statement and a mis-typed content-type.
On my Apache webserver i can server PDF files directly in the Browser with a simple Anchor link like:
Click to display PDF
This Works fine.
Now, i've got a lot of PDF's i want to Protect. So i moved them all outside the Web folder, and are serving them through a PHP download program - i called it download.php
To be sure that the pdf files are not downloaded as "download.php" i have to set the Content-Disposition Header to 'inline;filename="mysample.pdf"'. Inline because i want to open it in the Browser.
No Problem, all works fine. the files are downloading fine on Windows and Apple Browsers and are displayed IN the Browser, just like when its served directly from the Apache Server.
But my download.php doesn't work with Android Browsers... It's always just downloaded but not opened in the browser. You have to find the file in your messages and open it separately. When served directly from Apache it IS opened in the Browser.
It seems to be connected with Content-Disposition Header im setting in my download.php, because this is the only difference i see in the headers when download direct and indirect.
Anybody had the same problem?
Thanks
Per
In my site, I give an option to upload images with .jpg and .JPG extension. They both work and I can see both on the server itself.
When I try to see in the browser the photos with the .jpg extension by calling them name.jpg, they work. When I call to the othername.JPG (which is called that way on the server) it does not work and does not show it. othername.jpg does not work too.
I suppose your web server is not configured to send the Content-Type: image/jpeg HTTP header for such files. It's possible that some browsers refuse to display them as pictures if the MIME type does not match. If you happen to be using Apache, you can fix it yourself in an .htaccess file:
AddType image/jpeg .JPG
You should also consider that you cannot count of URLs being case-insensitive: FOO can equal foo... or not. Use always the exact case and save yourself future problems.
Edit:
Before misconfiguring random stuff, you can follow this checklist and see what fails exactly:
Is the URL valid? Foo.jpg is not the same as foo.jpg.
Does the browser receive the file? Firebug should tell you.
What's the HTTP response code? Firebug should tell you.
What's the Content-Type header? Firebug should tell you.
Common status codes:
404: the file could not be found. Most likely, your URL is wrong.
403: you are not authorised to see the file. It can be a permissions issue.
500: generic server error code. You should open your hosting service control panel and have a look at the error log.
Your using linux/apache right? make the filenames lowercase. its the default for them to be accessed on linux.
try to check the contents of that file, maybe your script is messing up JPG uploaded files.
if that doesn't work maybe it's from your system .. an .htaccess
Look in error logs for anything that is related to this file.
I'm serving up Zip and PDF files on the fly via PHP using an output such as:
header('Content-Disposition: attachment; filename="'.$project->name .'.zip"');
echo($zipfile->zl_pack());
I can't find any reference to these downloads in my APACHE logs though. Is it not logged due to being dynamic?
Do I need to actually write the file to the webserver and then serve the result up to get it logged or am I missing something?
Cheers,
Niggles
Correct. httpd does not look at outgoing headers for logging. error_log() will send a message to httpd's error log, but there's no way to put something in the access log.
The request to the PHP program that generates that header should be logged. The filename mentioned in the content disposition header won't be.
I believe mod_perl would allow you to add custom logging, I don't know if mod_php provides a similar feature.
As a workaround you could use mod_rewrite to have the *.zip file logged and still served it through PHP without actually writing it to the filesystem, the client will have to send two requests though.
1) Change your current script so that it doesn't produce the file, but instead puts the parameters needed for the file creation in the session; instead of the current header and file content you would put header('Location: '.$project->name .'.zip');
2) This would cause the second request. Since the requested file doesn't exist yet, you would use mod_rewrite to change the request to a *.zip file to the same or some other PHP script that reads the parameters from the session and produces the file just like you're doing it now. If you use the same PHP script, you would additionally let mod_rewrite add some parameter like "?action=produceFile" to the request and then test for that parameter in the script.
This way you would have two nice entries in your Apache log without having to physically save the file (and probably delete it later).
FYI I found a really good work-around.
Part of the problem was that we wanted to force a "save as" dialogue as many of the users get confused as to where the file gets saved. So this is why I went the
Content-Disposition : attachment
method.
A better method which still invokes the dialogue is to add this to .htaccess
<Files *.zip>
ForceType application/octet-stream
Header set Content-Disposition attachment
</Files>
write the Zip to the fileserver and redirect the page to the zip.
Sure I have to cleanup every night, but it gets logged and it still forces them to choose where they download the file (on pretty much everything but Safari [ there's always one ]).
Cheers,
Niggles