I have a form that points (action) to an url: http://www.mysite.com/actions/process.php?id=12. In this case the post variables are not detected. If I change the url to: actions/process.php?id=12 all works fine.
The big problem is that my form is situated into an include file and the directory of the output files (the pages with the form inside) may change their directory and for this reason I need to use the full url.
But with the full url POST doesn't work...
I forgot to say that the form is submitted by javascript:
document.getElementById('form').submit();
With a normal form it works fine even with a full url...but not if submitted with javascript! I use javascript because of the design of the submit button, I'm forced to do so.
PS: no errors in javascript console
How can I fix it?
PS: I'm working on Ubuntu server with apache installed
Related
I have recently moved from localhost to my live website. I have a simple PHP login page. After the users details are checked with my mysql table and if the username exist and they provide a valid password for that username they are redirected to the home page. I was using the header function built in to PHP but this seems to be no longer working now that I am on my live website.
After further research it seems that I cannot use header tags after the page loads. So I am not echo'ing out script tags to window.location redirect to my homepage. The problem with this is that when the new location is being redirected to it appears to look like an additional web pages is loading in before my actual webpage that I'm wanting to go to loads in (This is probably due to the fact that I have extra error handling code that is running after the fact). Does anyone else experience this when using this method? Is there a better way to handle this?
This is what I'm using currently just in case there is any confusion
echo '<script>window.location.href = "home.php";</script>';
I was using the header function built in to PHP but this seems to be
no longer working now that I am on my live website.
Headers must be the very first thing that your script outputs or they won't work. PHP has a convenience feature called output buffering which temporarily holds back the output until the script is done. This allows you to put calls to header() anywhere in your code, and then PHP will automatically take care of moving headers to the front of the output for you. Thus, if you have output buffering enabled, you can put headers anywhere and it will still work. If you do not have output buffering enabled, you must put headers at the very start.
I will wager that you are generating output before the headers, and your local PHP install has output buffering enabled, while your remote host does not. You can fix this in one of two ways:
Update your code to ensure that nothing is output before calls to header().
Enable output buffering on your host by setting output_buffering = 1 in your php.ini.
I recently learnt you can do this with a meta tag:
<meta http-equiv="refresh" content="2;url=http://example.com/" />
1) situation:
On some page the user can use an file upload form to upload a text (or excel) file. After successful upload the user should be redirected to a page where he can do whatever with his file.
2) My controller class:
...
if (!$this->upload->do_upload('fileupload')) {
echo "error file upload not successfull";
}else {
redirect('import/filepreview/');
}
3) what happens
First nothing appears to happen. The file has been uploaded but the page doesn't change.
While using firebug extension it appears there has been sent a Header containing a get request to the proper target url and all the expected content is in the answer. But not displaying on site.
I actually don't know what I am doing wrong.
Solved the problem but only using a workaround.
Finally I used javascript redirection
window.location.replace("http://new.../x_id");
with an x_id which the servers answer to the file upload.
So everything works fine for me. But the original question, why CI's redirect does not work is still open for me.
I have a PHP script that's outputting a CSV file and up until now I've been just using a link and passing parameters that are used to determine the output in the GET data. However recently the size of the data increased and now that code gets Error 414 - Request URI too Large. I tried using a hidden form to do it with POST but it just reloaded the page and didn't supply a prompt to download the file and all of the suggestions I've been able to find online about doing it with AJAX suggest using a link with GET data instead. Does anyone know a workaround that will have the browser still let the user easily download the data?
Presently I'm just setting the href attribute of a <a> tag.
$("#exportCSV").attr('href', "myscript.php/?data=" + exportData);
exportData has become too long for GET data but I want to maintain the behavior where if you click on a link that has say a CSV file being outputted the browser provides a download dialog for the user.
In our web portal we generate PDFs for certain kinds of data. The user downloads the PDF by clicking an tag that references something that we return with content-type: application/pdf;charset=utf-8
This works well when it works; the browser realizes that it is getting a PDF file and opens a internal or external PDF reader, or asks the user to save the file, depending on browser and user configuration.
We have some cases where we may fail to generate the PDF though. First we didn't handle the error, a NullPointerException fell through and we got an ugly new page full of JSON formatted garbage. Then we tried returning an empty result, which the browser thinks is fine and just saves or sends an empty file. Then I tried returning a redirect, which confused Chrome which showed an alert telling the user that something strange was happening.
The href in the tag is on the format "/module/showmypdf.cmd?pdfid=67482". This, as I said, works fine when a valid pdf is returned.
So, is there any kind of best practice for error handling when it comes to sending non-HTML files to browsers? Is there something else I could try to make the browser interpret my response as a redirect?
Ok I figured out why the redirect didn't work. I was doing this in my Java Spring controller:
response.sendRedirect("redirect:mypage.html?pdfError=true");
The "redirect:" prefix is something you can use when returning the view name from a controller. In the sendDirect() call it only adds confusion. Removing "redirect:" fixed it.
Having uploaded my JavaScript, PHP and other relevant files to the web hosting server and tried to run them on browser I had the following error:
Resource interpreted as Script but transferred with MIME type text/html: "http://stats.hosting24.com/count.php".
It seems that the html and php files works fine but I assume there is a problem with the js files. I would immensely appreciate if anyone could explain what the actual problem is and how it can be resolved.
Best..
You seem to be using 000webhost, which I know, from experience, inserts a bit of HTML at the end of your HTML that triggers that specific warning in Google Chrome. You'll find this at the end of your page source:
<!-- Hosting24 Analytics Code -->
<script type="text/javascript" src="http://stats.hosting24.com/count.php"></script>
<!-- End Of Analytics Code -->
The page at the URL has an empty response body, which suggests that it is simply a script that records analytics data. No actual JavaScript is returned.
How to Fix the Problem
I was able to fix the problem by disabling that extra bit of HTML. Go to http://members.000webhost.com/analytics.php and fill the form out. The password is the same as the one that you use to connect to your server via FTP. Under "Manage analytics code," choose "Disable Code." Click Submit, and the warning message should go away the next time that you refresh your webpage.
If you don't know the FTP password for your domain, you can change it by logging into your account, clicking "Go to CPanel" under the domain in question, and clicking "Change Account Password" under Main Menu.
Mime type means the type of file that you want your end data to produce. Here is a list of mime types:
http://en.m.wikipedia.org/wiki/Internet_media_type#section_1
The server was saying: "do you want me to process a script? Or do you want me to display this code as html."
It is receiving a script and you want it to display an html. So, the server was confused.
You need to specify the content type in your PHP:
header("Content-type: application/javascript");
In the case of this particular error, the PHP code (I assume) is actually spitting out JavaScript code. By default, Apache will send the contents of any PHP file as HTML, so the web browser receives the script but thinks it should be HTML. The browser is smart enough to "get over" the problem and interpret the script, but if you want to stop the error, make PHP let Apache know that it is returning JavaScript with this:
header("Content-type: text/javascript");
You could use
AddType text/javascript .js
in yout .htaccess / httpd.conf