Jump to content

500 internal error on update file list


Recommended Posts

hi i have uploaded a 13gb .zip as a digital product via ftp

and when i press update file list it comes up with

 

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at xxxxxxxxxto inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Link to comment
Share on other sites

This additional part of the response:

"Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request."

suggests that the error is being triggered by the web server itself.

So, see if there exists a web server error log -- if being hosted, you may be able to fetch/view the web server logs via the hosting control panel.

 

Link to comment
Share on other sites

First is to ask them to examine any web server error logs. Then, make any necessary adjustments to what triggered the 500ISE.

That could be a trigger on suspect sequences of characters in GET or POST (as determined by any security application installed on the server), a misconfigured directive in any .htaccess file, or (because we actually haven't ruled out PHP errors) to give advice on any PHP errors -- even though there isn't a viewable PHP error log being written in CubeCart's main folder.

 

Link to comment
Share on other sites

im still getting a

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at  to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Link to comment
Share on other sites

i have spoke to the web hosting

 

I have checked the error_log file located in the domain directory and afraid to see the following error:
PHP Warning:  POST Content-Length of 13922528066 bytes exceeds the limit of 5410652160 bytes in Unknown on line 0

 

It looks like the issue you are seeing on your website is not caused by any wrong server configurations. As scripting/coding is something beyond scope of our support, we would request you contact the Web developer or application vendor to check on this and let us know if they would need us to make any changes from our end towards resolution. We'll be more than happy to check it for you.

 

Link to comment
Share on other sites

For some reason, CubeCart is wanting to load into memory that 13GiB file, but the environment is set at 5GiB - thus running out of memory.

So, we need to figure out why CubeCart wants to examine this file (possibly to create some sort of hash code based on the contents).

Then try to convince CubeCart to not do this on large files.

 

Edited by bsmither
Link to comment
Share on other sites

I made an experiment on an installation that was given 256MiB memory, where I placed a 360MiB zip file in the /files/ folder, then had CubeCart Update File List.

If any part of CubeCart were to read in that file to memory, I would expect a "Out of Memory" error.

However, looking again the error message posted above, I now notice that "POST Content-Length" has been exceeded.

In admin, PHP Info, scroll to the "core" table and find the 'post_max_size' value. Maybe it's 5000M?

If the error message is to be believed, it seems there was an attempt to have the browser do the file upload of the 13GiB file (which was worked around by FTPing the file).

Link to comment
Share on other sites

what is happening at the moment is that im ftping the 13gb file and when i go to press the update file list the browser crashes

 

my.zips are big zips and it seems strange that you guys have set digital downloads to be one file only ?

 

surely if im able to tick multiple images per product i should be able to tick numerous digital files per download

as im having to zip all the files into one file making it too big to upload basically

 

 

Link to comment
Share on other sites

So we are still working on the Update File List problem.

I also think we can eliminate the error message that was last mentioned as an indicator of what went wrong.

The most recent versions of CubeCart keeps the debug results spooled in the session file, ready to unspool whenever CubeCart delivers a viewable page.

This means that if CubeCart is set to have its debug mode enabled (admin, Store Settings, Advanced tab, Debug Mode enabled, and also your local IP address (www.showmyip.com) entered in the following text field), we can examine what was the last database query made, which will give us a clue as to where to focus our investigation.

(I need to find a 13GiB zip file for further experiments.)

 

 

Link to comment
Share on other sites

it would be easier to make the uploads unlimited and via the browser with a progress bar like youtube is

 

it seems very old school to be upping via ftp and then having to refresh on the other side once complete

upping images is fine and you get progress bars etc

 

but i feel as the world is going digital and bitrates getting bigger and hard drives getting bigger it seems the way forward would be a unlimited upload in browser session with progress bar etc

Link to comment
Share on other sites

I created an 8GiB zip file to test this situation.

The web server waited 60 seconds (default) for PHP to respond, resulting in a 504 Gateway Time-out. (An error was logged in the web server's error log.)

I see no evidence that PHP actually timed out (no error logged), and the database got the record inserted. My diagnostic tracing shows that the task completed successfully.

Seeing as how long it took my system to calculate the MD5 hash for the newly discovered file (approx 70 seconds, even though PHP is set to have a max_execution_time of 60 seconds, and did not run out of memory -- max used 12.5 MB), I have to imagine that the machine running your site also took about that long.

The database record for the newly found file is being built in the FileManager class, near line 297. Of concern is the PHP function md5_file().

I believe this is the culprit.

"when i go to press the update file list the browser crashes"

Was there a significant time delay between when you clicked on the Update File List tab and when the browser indicated an error? Or was it immediate?

To solve this, not only must we (to be safe) increase PHP's max_execution_time, but also the web servers timeout setting to something longer - maybe 120 seconds?

 

Edited by bsmither
Link to comment
Share on other sites

Do you have complete control of the server hosting your site? (dedicated or virtual)

If so, what is the web server? Apache? Nginx?, Litespeed?

Let's try to adjust the timeout setting of the web server to wait twice as long for PHP to process that 13GB file.

As an aside, would you be willing to beta test something?

 

Link to comment
Share on other sites

my hosting has changed all the settings but now the file only shows 4gb out of 13gb on my browser now

the hosting has said

Looks like there is limits with file upload in cubecart. That is the reason only 4 GB is getting upload

Link to comment
Share on other sites

Here's an interesting conversation that answered quite a few of my questions about this:

https://forums.phpfreaks.com/topic/313075-function-md5_file-limits/

If possible, please use phpMyAdmin to view the CubeCart_filemanager table directly. What does the filesize say?

I just now looked at my CubeCart_filemanager table and I see that the 8GiB file has a reported filesize of "4294967295" -- which "4GiB - 1" bytes.

The actual query (as recorded in my diagnostic trace) specified "9117468856" as the filesize -- which is just shy of 8.5GiB <- it's true size.

So, let's look at the database table schema for CubeCart_filemanager. That column is declared for INT. The MySQL data type of "unsigned INT" can hold a maximum value of 4294967295. See:

https://dev.mysql.com/doc/refman/5.7/en/integer-types.html

I would say the next step is to alter the CubeCart_filemanager table, 'filesize' column to be a "unsigned BIGINT". You might also bump the column's schema attribute 'length' from 10 to 12.

 

Edited by bsmither
Link to comment
Share on other sites

There is also another instance of using md5_file in the FileManager class, getFileInfo(). This is in a section of code where the product was given a digital path (as opposed to having had a file assigned to the product) to a file that exists somewhere on the server (near line 914).

So, in this situation, a file not specifically 'assigned' to a product, but indicated in the digital path text entry field, when getting ready to deliver that file, there will be that 100 second dead time.

Here's an interesting question you can ask your host: does your hosted environment use hard drives, or SSD storage drives?

Edited by bsmither
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...