TYPO3 Core

This means that the new feature Dmitry implemented, i.e. throwing 503-headers when the "page is being generated" message is displayed has a bug, because it throws the 503-header also in cases where it should not be thrown.

Someone else on the German mailinglist had the same problem, but could unfortunately not provide further details.

cheers,
Ingmar

It means that page is NOT generated properly by typo3.

"503" temporary content is placed to the cache only until proper content is returned by pagegen script. Then "503" is removed.

I will take a look at it. Since it works with normal pages, my initial assumption is that pdf generator is not doing something. I can be wrong of course...

The same problem occurs with tt_news, when you included it via TypoScript on every page (through a template marker or something) and disallowed the caching of the extension with "plugin.tt_news.allowCaching = 0". Then TYPO3 sends on every page call the 503 header.

Can Yavuz, thanks, this helps a lot!

Could not reproduce it with pdf_generator. Here is debug output from wget:

dima@BIGBRO:~/tmp/htmldoc-1.8.25> wget -d -O out.pdf "http://typo3w/index.php?id=1&type=123" 
Setting --output-document (outputdocument) to out.pdf
DEBUG output created by Wget 1.10.1 on linux-gnu.

--16:35:45--  http://typo3w/index.php?id=1&type=123
           => `out.pdf'
Resolving typo3w... 127.0.0.1
Caching typo3w => 127.0.0.1
Connecting to typo3w|127.0.0.1|:80... connected.
Created socket 4.
Releasing 0x08088f28 (new refcount 1).

---request begin---
GET /index.php?id=1&type=123 HTTP/1.0
User-Agent: Wget/1.10.1
Accept: */*
Host: typo3w
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Sun, 02 Apr 2006 13:35:45 GMT
Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.8a DAV/2 PHP/4.4.1 mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.2 Perl/v5.8.7
X-Powered-By: PHP/4.4.1
Set-Cookie: fe_typo_user=c22936256f; path=/
Content-Disposition: inline
Cache-control: private
Connection: Keep-Alive, Keep-Alive
Content-Length: 713445
Keep-Alive: timeout=5, max=100
Content-Type: application/pdf

---response end---
200 OK
Registered socket 4 for persistent reuse.

Stored cookie typo3w -1 (ANY) / <session> <insecure> [expiry none] fe_typo_user c22936256f
Length: 713,445 (697K) [application/pdf]

100%[===============================================================================================================>] 713,445       --.--K/s

16:35:45 (26.91 MB/s) - `out.pdf' saved [713445/713445]

dima@BIGBRO:~/tmp/htmldoc-1.8.25> wget -d -O out.pdf "http://typo3w/index.php?id=1&type=123&no_cache=1" 
Setting --output-document (outputdocument) to out.pdf
DEBUG output created by Wget 1.10.1 on linux-gnu.

--16:37:09--  http://typo3w/index.php?id=1&type=123&no_cache=1
           => `out.pdf'
Resolving typo3w... 127.0.0.1
Caching typo3w => 127.0.0.1
Connecting to typo3w|127.0.0.1|:80... connected.
Created socket 4.
Releasing 0x08088f70 (new refcount 1).

---request begin---
GET /index.php?id=1&type=123&no_cache=1 HTTP/1.0
User-Agent: Wget/1.10.1
Accept: */*
Host: typo3w
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Sun, 02 Apr 2006 13:37:09 GMT
Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.8a DAV/2 PHP/4.4.1 mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.2 Perl/v5.8.7
X-Powered-By: PHP/4.4.1
Set-Cookie: fe_typo_user=b88a62c57e; path=/
Content-Disposition: inline
Cache-control: private
Connection: Keep-Alive, Keep-Alive
Content-Length: 713445
Keep-Alive: timeout=5, max=100
Content-Type: application/pdf

---response end---
200 OK
Registered socket 4 for persistent reuse.

Stored cookie typo3w -1 (ANY) / <session> <insecure> [expiry none] fe_typo_user b88a62c57e
Length: 713,445 (697K) [application/pdf]

100%[===============================================================================================================>] 713,445       --.--K/s

16:37:09 (23.38 MB/s) - `out.pdf' saved [713445/713445]

dima@BIGBRO:~/tmp/htmldoc-1.8.25>

Neither it happens with tt_news. I believe it is already fixed. See discussion named "problem with caching still exists in current CVS" here: http://lists.netfielders.de/pipermail/typo3-team-core/2006-March/thread.html

I set bug to "resolved" now. Feel free to set back to assigned if you still have problems with recent CVS version.

See notes for details

Hi Dmitry,

I'm afraid this bug has to be reopend, because I managed to reproduce the error.

It occurs when fronend plugins of the type USER (not USER_INT!) disable caching using the following line:
$GLOBALS['TSFE']->set_no_cache();

Looks like a good candidate for a 4.0.1.

cheers
Ingmar

Fortunately there are not so many of them. Sad that it was not discovered before 4.0 final... Anyway, I will look at it.

Thanks again! This is really helpful.

The following patch should fix the problem:

Index: class.tslib_fe.php
===================================================================
RCS file: /cvsroot/typo3/TYPO3core/typo3/sysext/cms/tslib/class.tslib_fe.php,v
retrieving revision 1.104.2.21
diff -u -r1.104.2.21 class.tslib_fe.php
--- class.tslib_fe.php  25 Mar 2006 18:07:03 -0000      1.104.2.21
+++ class.tslib_fe.php  9 Apr 2006 10:55:02 -0000
@@ -2782,7 +2782,7 @@
                }

                        // Send appropriate status code in case of temporary content
-               if ($this->tempContent) {
+               if ($this->tempContent && !$this->no_cache) {
                        $this->addTempContentHttpHeaders();
                }

Sounds reasonable.

But I wonder why $this->tempContent is set to 1 in the first place when set_no_cache() is used?

Shouldn't the tempContent flag be true/false depending on whether the content output to the browser is the "Page is being generated" message?
So how come the value is 1 even if the normal page is generated, just with the set_no_cache()?

cheers
Ingmar

Q: But I wonder why $this->tempContent is set to 1 in the first place when set_no_cache() is used?
A: This is how cache works. Before page generation even starts, temporary content is created and put to cache. This is "Page is being..." message. Such generation always happens. tempContent is set to true to indicate that we have temporary content. After content generation code looks if content is cachable. If it is, it replaces temporary content with generated content. If no, it removes temporary content from the database. In any case, tempContent flag is set even before we know if page is cachable or not. If we do not set it, we will not know that we have to send 503 status if error occurs.

Q: Shouldn't the tempContent flag be true/false depending on whether the content output to the browser is the "Page is being generated" message?
A: This how it should work. Just take into acount that this message also goes to cache.

Q: So how come the value is 1 even if the normal page is generated, just with the set_no_cache()?
A: Because of cache logic. Temporary content is generated always. Then there are two branches in the code (see near line 2573 in tslib_fe.php): one for cached content, one for non-cached. In fact your question gave me idea for better patch ;) I'll need to check it better but here it is for testing:

Index: class.tslib_fe.php
===================================================================
RCS file: /cvsroot/typo3/TYPO3core/typo3/sysext/cms/tslib/class.tslib_fe.php,v
retrieving revision 1.104.2.21
diff -u -r1.104.2.21 class.tslib_fe.php
--- class.tslib_fe.php  25 Mar 2006 18:07:03 -0000      1.104.2.21
+++ class.tslib_fe.php  9 Apr 2006 11:56:29 -0000
@@ -2575,6 +2575,7 @@
                        $this->realPageCacheContent();
                } elseif ($this->tempContent)   {               // If there happens to be temporary content in the cache and the cache was not cleared due to new content put in it... ($this->no_cache=0)
                        $this->clearPageCacheContent();
+            $this->tempContent = false;
                }

                        // Sets sys-last-change: