Import well done but on refresh import.php, file too big error displayed #12368

yves-lndm opened this Issue Jul 7, 2016 · 11 comments


None yet

4 participants


Steps to reproduce

  1. Install apache2.4, mysql5.5, php5.6, phpmyadmin4.2 (all from debian)
  2. use import tab, add a file (even a very small)

Expected behaviour

After progression bar and message "ok, x lines imported", refresh of page and error message with "file too big". This second message should not be displayed

Server configuration

Debian 8.1
Mysql 5.5.49-0+deb8u1-log
phpMyAdmin 4.2.12deb2+deb8u1
PHP 5.6.22+dfsg-0+deb8u1
with config :
memory_limit 256M
upload_max_filesize 128M
post_max_size 128M

Client configuration

Google Chrome 51.0.2704.103 m

Operating system:
Windows 10 home 64b


Hi @yves-lndm the version 4.2 is not supported now. Could you try and reproduce the error on the latest version 4.6.4 ?

@devenbansod devenbansod added the question label Oct 3, 2016
yves-lndm commented Oct 7, 2016 edited

I have installed lastest version (4.6.4) and got exactly the same thing (the error message is displayed twice). Can this come from APCu ? :

In the "import tab", the max file size is 128Mb and I've got the error message with only a 12Mb sql file (the file is well imported, but the error is displayed after).


Actually the error message is display since no POST or GET parameters are set and import.php is called with no parameters (when refreshed).
When such an event occurs (no POST or GET parameter is set), there are two possibilities

  1. Either user has called import.php directly (which generally should not happen) OR
  2. Upload Limit has been reached

Currently, we 'assume' the second possibility and show that error. I suppose we might be able to improve the error message to include the first possibility as well.

yves-lndm commented Nov 28, 2016 edited

After two step by step installations, I've found from where this is coming.

If you set

Header set X-Frame-Options: "sameorigin"

in /etc/apache2/conf-enabled/security.conf, you will have the error. It's seems the iframe is seen as from another domain.

nijel commented Dec 1, 2016

@yves-lndm Setting this in Apache will probably break things as phpMyAdmin itself sends this header as well and some browsers have problems parsing response if the headers is present twice, see also #12629.


@phpmyadmin/developers Is there something for us to improve here?

nijel commented Dec 19, 2016

I don't really see way we can handle this reasonably. There is no way to figure out server headers from PHP and we want to issue such headers. Maybe we could document what (security related) headers do we use and that we expect the web server not to handle them for php files (while it might be useful to do that for static files).


This header is a server side parameter and security stuff have to be set on from a server side point of view, IMHO.

Each application do not set this header and by setting it in phpMyAdmin, you enforce to modify server configuration, so all others vhost have no longer the header on and by this way you create a breach and not a security enhancement.

nijel commented Dec 20, 2016

Each application do not set this header

Sorry, that doesn't seem to be true, just randomly looked at two PHP applications:

Anyway you can disable this particular header by $cfg['AllowThirdPartyFraming'].


All the web site or web application is not based on this 2 CMS, but I have some sites on the same server using WP and I never notice that kind of error.

WP source code may be a good start of investigation ? Perhaps they find a way to check header before send it twice ?...

If I use $cfg['AllowThirdPartyFraming'], will this stop only that particular header and nothing more ? In that case, that's a solution because the header will always be send by the server configuration and so don't allow phpMyAdmin in a frame.

nijel commented Dec 20, 2016

WP is sending this unconditionally on login pages. As I've said before, there is no way to figure out if server will add some headers to the response PHP generates as the server does this after PHP runs.

Disabling $cfg['AllowThirdPartyFraming'] will also disable javascript based cross framing protection.

@nijel nijel self-assigned this Jan 18, 2017
@nijel nijel closed this Jan 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment