Solving the squid 'connection reset' problem

[Will Moffat]

Hi,

We support FirePHP headers on Acre, the ServerSide JavaScript
environment for Freebase.com

Large headers cause squid to kill the connection:
http://code.google.com/p/firephp/issues/detail?id=35

Acre is stateless and we don't want to introduce a DB just for logs,
so our solution was to return the headers, logs and body as JSON.
Here's an example: http://gist.github.com/294285
We then document.write() the body into the page.

Any chance of FireConsole implementing a similar approach?

regards,
--Will
Will Moffat
FreebaseApps.com

[Christoph Dorn]

> Large headers cause squid to kill the connection:
> http://code.google.com/p/firephp/issues/detail?id=35
>
> Acre is stateless and we don't want to introduce a DB just for logs,
> so our solution was to return the headers, logs and body as JSON.
> Here's an example: http://gist.github.com/294285
> We then document.write() the body into the page.
>
> Any chance of FireConsole implementing a similar approach?

FireConsole currently supports the following three modes of operation:

1) All data is sent in the response headers (which fails if there is too
much data)

2) A URL is sent in the response headers for FireConsole to make a
second request to fetch the console data

3) The page marshals log messages into the console via Firebug's
console.log() with a special object property indicating which template
should be used to render the object.

Option (2) can be achieved quite easily in a stateless environment. All
you need is a memcached server (or message queue etc...) and a way to
query keys via public URLs. On an app server, the server lib collects
the log messages, bundles them into one structure and stores them in a
central server via a computed key. The same key is sent in the response
headers as part of the URL FireConsole can query to get the data.

Option (3) can be used together with a custom template pack to render
objects logged via console.log() that have a "__fc_tpl_id" property set.
I will be going through this in detail next week.

While option (3) will work with your current implementation, it is not
ideal as the response is no longer valid HTML nor equivalent to the
actual production setup. This may not be a problem in your controlled
app-builder interface.

Christoph