Coralized URLs preserved through redirection

(Note: Due to excessive spam, we have turned off public editing of this page. If you would like something added, please email us.)

The Coral syntax works in some unexpected places, due to the fact that a Coral proxy will rewrite the location URI sent back in HTTP redirects.

For example, SnipURL is a free URL abbreviating service. Coralizing a Snipped URL works, in the sense that the browser will be sent to the Coralized version:

forwards to the Coral cache of this page.

Coralized URLs with refresh

Some URIs, normal enough in the regular context, may lead to unexpected results when accessed through Coral. Some sites use a META refresh tag to cause the browser to re-issue a new HTTP GET request after some specified number of seconds. Coral may be used in this context, but users must consider what happens when the refresh URI specified is one of the following:

  • Coralized absolute URI: The Coralized page will be requested, as expected.
  • Non-Coralized absolute URI: The non-Coralized page will be requested, even if the original page was accessed via Coral. However, the freshness of the fetched object can differ, as explained with respect to relative URIs.
  • Same relative URI: While a non-Coralized version of this page will work as expected, within Coral it would fall under Coral's minimum 5 minute caching rule. Thus, the "new" page fetched after the refresh timeout will not change during the caching period, preventing users from receiving fast updates as desired.
  • Different relative URI: Given a new URI upon each refresh, the previous caching rule will not interfere with users receiving quickly-updating pages, via Coral or otherwise.

Transparent Redirection using mod_proxy in combination with mod_cache

If you are running a site, that may be DOSed by getting digged or slashdotted, you may consider to add the following configuration to your apache (2.2 up). If the configuration is active (you may prepare it in a separate file and include it in case of such an event), this happens: requests to your page will be transparently proxied by mod_proxy to the Coral network. Once a URL has been fetched via mod_proxy it will be stored in the cache using mod_cache. Subsequent requests will be answered directly by mod_cache without the use of Coral. Furthermore you can add exceptions for URLs which have to be delivered directly uncached (e.g. a contact form, a comment form or an admin backend of a blog).

Here's the config:

# load the required modules
LoadModule cache_module      libexec/apache22/
LoadModule disk_cache_module libexec/apache22/
# you may also use mod_mem_cache instead of disk_cache
LoadModule proxy_module      libexec/apache22/
LoadModule proxy_http_module libexec/apache22/

# the cache config, tweak to your needs. There are lots of
# more optpions, refer to the apache documentation for details
<IfModule mod_disk_cache.c>
  CacheRoot /tmp/cache
  CacheEnable disk /
  CacheDirLevels 5
  CacheDirLength 3

# enable reqwriting. If you have already configured some rewriting,
# then these rules must be the first ones!
RewriteEngine on

# exception for the Coral bot, show it the real content
RewriteCond %{HTTP_USER_AGENT}  !^CoralWebPrx*

# exception for content not to be cached (e.g. comment form)
# add more lines like this, one per url. you may of course
# use regular expressions here for more flexibility
RewriteCond %{REQUEST_URI}      !^/comment\.php

# pass everything else via mod_proxy (the P flag) to Coral.
# let this be the very last rewrite rule (the L flag) and
# deliver the result to the requesting client. The request
# URL doesn't change this way
RewriteRule ^(.*) http://%{HTTP_HOST}$1  [P,L]

As mentioned earlier, put this config along with all required exceptions into a separate config file, add an include statement to your main apache config and comment it out. If a DOS occurs, remove the comment and reload the webserver.