wiki:Flow

The request & response flow: How GlimmerBlocker works

This page documents how requests and responses flow thru GlimmerBlocker. It starts with a simplistic description which is then extended bit by bit to the complete description.

Extremly simplified flow

This is what happends with most requests/responses: those that are not blocked or modified.

  1. Safari sends the request to GlimmerBlocker
  2. ..GlimmerBlocker sends the request to the web-server.
  3. ..The web-server sends the response to GlimmerBlocker.
  4. GlimmerBlocker sends the response to Safari.

To speed up the response, the last two steps are performed concurrently, i.e. the response is streamed. GlimmerBlocker doesn't wait until it has received all of the response before it starts sending it back to Safari. Each time GlimmerBlocker has received a bunch of bytes, they are transmitted back to Safari. So the steps are really:

  1. Safari sends the request to GlimmerBlocker
  2. ..GlimmerBlocker sends the request to the web-server.
  3. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Filter Rules

When GlimmerBlocker has received a request, if finds all the matching rules and sorts them by priority.

Assuming the first rule is a "whitelist URL" rule (which doesn't want to modify content), the above list of steps is extended to:

  1. Safari sends the request to GlimmerBlocker
  2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
  3. ..GlimmerBlocker gets a "whitelist URL" rule.
  4. ..GlimmerBlocker sends the request to the web-server.
  5. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Blocking ads by URL

When the first rule has action = block, the steps are:

  1. Safari sends the request to GlimmerBlocker
  2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
  3. ..GlimmerBlocker gets a "block URL" rule.
  4. GlimmerBlocker sends back a transparent 1*1 pixel gif as response to Safari

The processing of the request is stopped at this place and the web-server is never contacted. For Safari, it seems like e.g. "doubleclick.net" always sends 1*1 pixel gifs no matter what the URL-path is.

Modifying responses

When the first rule wants to modify the content, e.g. adding a bit of css:

  1. Safari sends the request to GlimmerBlocker
  2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
  3. ..GlimmerBlocker gets a "modify content" rule.
  4. ..GlimmerBlocker sends the request to the web-server.
  5. ..The web-server sends the response to GlimmerBlocker, which buffers all of the response (i.e. no streaming).
  6. GlimmerBlocker executes the transformation javascripts and adds css/javascript snippes.
  7. GlimmerBlocker sends the modified response to Safari.

Modifying requests

The request rules can send back some fixed response, change the url, specify some request-specific dns server or proxy. The request-rule javascripts are executed by GlimmerBlocker (not by Safari) before the web-server is contacted (if at all).

Sending back a fixed response:

  1. Safari sends the request to GlimmerBlocker
  2. GlimmerBlocker executes the script in the first matching request rule.
  3. The rule sets the global t variable to e.g. "<script>window.close();</script>"
  4. GlimmerBlocker sends this as the response to Safari.

Changing the URL: redirects

  1. Safari sends the request for "http://www.nokia.com" to GlimmerBlocker
  2. GlimmerBlocker executes the script in the first matching request rule.
  3. The rule executes gb.response.sendRedirect("http://www.apple.com/iphone");
  4. GlimmerBlocker sends a redirect-response back to Safari.

Safari will then fetch the Apple page using another request. This can be useful for sites which splits up articles into a gazillion pages and where you want to automatically redirect to the "single page" or print-friendly version.

Changing the URL: concealed/hidden

  1. Safari sends the request for "http://www.nokia.com" to GlimmerBlocker
  2. GlimmerBlocker executes the script in the first matching request rule.
  3. The rule sets the gb.request.url variable to e.g. "http://www.apple.com/iphone"
  4. GlimmerBlocker sends the request to Apple's web-server.
  5. Apple's web-server sends the response to GlimmerBlocker, which streams it back to Safari.

In this case, Safari still thinks the page has an address of www.nokia.com, it doesn't know that the page was fetched from Apple. It is not a redirect!

Changing the dns server:

  1. Safari sends the request for "http://www.apple.com" to GlimmerBlocker
  2. GlimmerBlocker executes the script in the first matching request rule.
  3. The rule sets the gb.network.dnsServers variable to e.g. "208.67.222.222"
  4. GlimmerBlocker uses this dns server to resolve "www.apple.com"
  5. GlimmerBlocker sends the request to web-server.
  6. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Changing the proxy server:

  1. Safari sends the request for "http://www.apple.com" to GlimmerBlocker
  2. GlimmerBlocker executes the script in the first matching request rule.
  3. The rule sets the gb.network.httpProxy variable to e.g. "proxy.example.com"
  4. GlimmerBlocker sends the request to the proxy-server.
  5. The proxy-server forwards the request to the web-server, which contacts the web-server.
  6. The proxy sends the response to GlimmerBlocker, which streams it back to Safari.

When a request rule changes the proxy or dns server, the change is request-specific, i.e. it doesn't "hang on" to the following requests.

  1. The object reference
  2. Proxies
  3. Transformation of responses
Last modified 5 years ago Last modified on 07/12/09 15:24:08