Bug #14340
closed
Typo3 3.7.0 Backend Does not work on some hosts that work with 3.6.2
0%
Description
After logging http://my~site.com/typo3/ it gives the error http://my~site.com/typo3/alt_main.php
The following error was encountered:
Zero Sized Reply
Squid did not receive any data for this request.
After looking at that file alt_main.php commenting lines 116 out and then commenting out lines 194 - 207 the busy_checkLoginTimeout_timer() for the javascript menu the Backend loads partially but the internal frames gives errors.
The same type of errors as before except with the http://my~site.com/typo3/alt_menu.php for the left frame and http://my~site.com/typo3/alt_intro.php, I stopped debugging from there because I think problem is not simple.
Tried all dummy packages
1. Typo3 3.7.0 source with Dummy 3.7.0 tar.gz
2. Tried Dummy-3.7.0 zip package as well
Server Information
PHP version: 4.3.4
Mysql Version: 4.0.20-standard
No PHP memory limits
All packages of Typo3 3.6.2 work on this server
(issue imported from #M392)
Updated by Daniel Poetzinger about 20 years ago
Sure that this is a bug in TYPO3?
I think it has something to do with squid? If we know what exactly causes the behavior, one could solve the problem.
A search for:
squid "Zero Sized Reply"
in Google found more than 2000 sites but I have never used squid.
bearbeitet am: 29.09.04 16:54
Updated by old_outrun about 20 years ago
What Causes the behaviour me loging in.
Squid is just the proxy/firewall im behind to acces the internet not the host
I thought so to begin with so I tried different proxies, it gave:
While trying to retrieve the URL: http://my~site.com/typo3//alt_main.php
The following error was encountered:
We can not connect to the server you have requested.
This means that:
The server might be busy at this time.
The server is not reachable.
Please try later to see if you can go through.
I thought it maybe a memory error - would the backend give a memory error? As I said before the server has no PHP memory limits. I didnt mention its shared hosting free -m gives this result
free m/+ buffers/cache: 953 1573
total used free shared buffers cached
Mem: 2527 2362 164 0 227 1181
Swap: 4095 237 3858
Updated by old_outrun about 20 years ago
Reminder sent to danp
For Bug 0000392 Ive tried another account on the webhost and it does the same thing would you like to have the url and password and details for my installation so you can see for yourself If it would help? My email address is q9922808@mail.connect.usq.edu.au if this note is inapporporate sorry.
regards,
Mark
Updated by Michael Stucki about 20 years ago
Doesn't look like a TYPO3 problem to me.
What does Squid say in its logfile?
Updated by old_burge about 20 years ago
I'm not using squid or anything related - I'm on a normal T1 connection and I've had this same error. Let me redescribe it. I've run previous versions of typo3, including 3.6.2, on the host, in this case 1and1.com When I updated to 3.7.0 everything on the front end worked fine and almost all backend functions worked. The problem occurs when a page is selected - the "page frame" is never rendered and the server reports the very informative "server error". I initially thought it was the new xml language files were taking too long to process on the "first time" but I edited these down to the bare minimum and am still getting this error.
Updated by Michael Stucki about 20 years ago
@burge:
What's the relation with this bug?
If you get a server error, have a look at your logfile and paste the error message here.
Updated by old_burge about 20 years ago
@Michael Stucki:
I thought this was a similar error because the internal frame was not displaying. In my case it is the "page frame" /typo3/sysext/cms/layout/db_layout.php?id=1 which produces a server error. It is frustrating because 1and1 do not provide access to any of the server error logs. I have turned on php debugging but can only get any errors reported if I lower the level to "notice". I know this is really difficut to debug w/out the server logs, and that is why I have just been monitoring this thread for the last month. But just in case this can help:
Notice: Undefined index: ext/cms/layout/db_layout.php in /etwas/30/mysite/htdocs/typo3_src-3.7.0/typo3/sysext/cms/layout/db_layout.php on line 1224
and so on...
Notice: Undefined index: default in /etwas/30/mysite/htdocs/typo3_src-3.7.0/typo3/sysext/lang/lang.php on line 454
edited on: 22.11.04 03:20
Updated by old_burge about 20 years ago
Just in case anyone is still monitoring this for the content element page rendering failure, it is now fixed in the current cvs:
The error occured during the initial processing of the xml language files. This process would fail silently when it exceeded the maximum allowed time/memory for a php process - leaving the processed files in an inconsistent state. 2004-11-15 Michael Stucki's cvs changes 1.139 on 2004-11-15 fix this. Updating to the current cvs distribution makes everything work again.
edited on: 02.12.04 17:40
Updated by Michael Stucki about 20 years ago
I'm quite sure this is a different problem. However there's nothing to do if we have no server logs. You should ask the support of 1and1, I see no other way... Please contact the installation mailing list for any further information/questions.
I'll keep this bug opened and wait if Outrun can give us some more details about this bug. If I don't get any feedback, I will close it.
Updated by old_outrun almost 20 years ago
Sorry I have been travelling, when I look at my log files after i log in it doesnt even do anything. Here you can see I go to typo3 login, I login after that nothing happens the last line shows me loging into cpanel, all the lines before are me logging in trying to login to the backend
202.7.187.12 - - [23/Nov/2004:00:30:54 0800] "GET /quick/typo3/ HTTP/1.0" 200 299 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:30:55 0800] "GET /favicon.ico HTTP/1.0" 404 - "http://outrun.com.au/quick/typo3/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]" " "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:30:58 -0800] "GET /quick/typo3/index.php HTTP/1.0" 200 5241 "
202.7.187.12 - - [23/Nov/2004:00:30:59 0800] "GET /quick/typo3/stylesheet.css HTTP/1.0" 304 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]" " "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:01 -0800] "GET /quick/typo3/md5.js HTTP/1.0" 304 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:02 -0800] "GET /quick/typo3/gfx/typo3logo.gif HTTP/1.0" 304 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:02 -0800] "GET /quick/typo3/gfx/loginimage.jpg HTTP/1.0" 304 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:02 -0800] "GET /quick/typo3/gfx/loginlogo_transp.gif HTTP/1.0" 304 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:02 -0800] "GET /favicon.ico HTTP/1.0" 404 - "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:04 -0800] "POST /quick/typo3/index.php HTTP/1.0" 302 0 "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:08 -0800] "POST /quick/typo3/index.php HTTP/1.0" 302 0 "http://outrun.com.au/quick/typo3/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.53 [en]"
202.7.187.12 - - [23/Nov/2004:00:31:29 -0800] "GET /cpanel HTTP/1.0" 302 209 "
P.S. burge Id like to know how you made the xml files to minimum id liek to try it over here.
edited on: 23.11.04 09:37
Updated by old_outrun almost 20 years ago
The Server upgraded to
PHP Version 4.3.10
Mysql Version 4.0.22-standard
The problem is now gone and backend works perfectly.
Updated by Michael Stucki almost 20 years ago
Fine. Is that ok if I close the bug then?
Updated by old_outrun almost 20 years ago
Yeah seems like no one else had this problem thanks for your time.
Mark