[TYPO3-core] RFC: "Page is being generated" and search engines

Dmitry Dulepov dima at spamcop.net
Tue Jan 17 09:53:28 CET 2006


Hi!

Martin Kutschker wrote:
> Dmitry Dulepov <dima at spamcop.net> writes on Some of you send the
> patch first and then the text message. This is great for my webmailer
> ;-)

Hm, did not get the idea :)

>> <script type="text/javascript"> -
>> window.setTimeout("location.reload()", 3000); +
>> window.setTimeout("location.reload()", 20000);
> 
> 20 seconds are a long time users will hit the reload button as early
> as 5 seconds. BTW, wasn't there a meta refresh in the HTML code?

This is true. But I was thinking about reducing server load. I played
with various timeouts on my own server and there I block all access for
30 seconds. It lowers server load withing 1 minute even when server was
under attack.

We can lower it to 10 seconds. I just think 5 is too fast. But I do not
insist. Make be we can even have a configuration option
(config.pageIsBeingGenerated_reloadTimeout or something).

> BTW, wasn't there a meta refresh in the HTML code?

We can set <meta http-equiv="refresh" content="20" />. Probably it would
be cleaner. I see no reason why script was used.

>> + function addTempContentHttpHeaders() { + header('HTTP/1.0 503
>> Service unavailable'); + header('Retry-after: 3600'); +
>> header('Pragma: no-cache'); + header('Cache-control:
>> private,no-cache,no-store'); + header('Expire: 0'); + }
> 
> We declare HTTP/1.0 but send HTTP/1.1 headers (Retry-after and
> Cache-control).

According to RFC 2145 says this is ok (see section 2.2):
-------------
For example, an HTTP/1.1 server may send a "Cache-control" header to an
HTTP/1.0 client; this may be useful if the immediate recipient is an
HTTP/1.0 proxy, but the ultimate recipient is an HTTP/1.1 client.
-------------
I found it right now but had proxies in mind when set 1.0 as a protocol
version. Interestingly that example mentions "Cache-control":)

According to HTTP specification all unknown headers should go unaltered
through proxies.


> And aren't private and no-cache mutually exclusive? Private
> explicitely allows browser caching, which doesn't seem to be what we
> want. Especially if we set no-store, which means "sensitive data,
> make no permanent copies".

Correct. It should be changed to "Cache-control: no-cache". I copied one
bad example from the web. My fault.

Dmitry.



More information about the TYPO3-team-core mailing list