The first is that the new code is much more flexible/reliable and will
be easier to customize, add conditions and new apis to, and generally
more readable.
There are also a few externally facing APIs that will need to change.
How we currently handle adding first_forward_domains and
exclude_from_retry domains is some hack/magic that lets you set a
domain string which will then be used for https:// and http://, in
order to make this code somewhat readable and unify the API i'm
deprecating that magic and only allowing full host strings, example: "http://www.addsite.com
". The name of the initial_forward_domains will also change to
initial_forward_domains. The new APIs will, in addition to accepting
regular strings, will accept regular expression strings. The reason we
have to regular expressions strings instead of regex objects is
because we plan on setting up a public blocklist that windmill will
pull down and it will need to be JSON serializable.
The name for adding proxy forwarding conditions will also change since
there are now two APIs, one that accepts the environ dictionary (like
the old API) and one that accepts a webenv request object (a new API).
I've also removed a lot of the old globals, so the old ways of
changing module level objects may go away if we can't find a clean way
of making it reverse compatible.
The new proxy should include most customizable response conditions
(for customizing when a request in a retry loop is valid) proper cross-
domain cookie handling (something that almost worked in the old code
but has to be removed due to a few bugs) and is also much more class
based with support for overriding whole classes and defaults.
A good checkin is on it's way.
-Mikeal
Hey Mikeal,
Just trying to get cookies and ssl working (at the same time :) and
found this post. Looks like cookies are disabled in the 'master' trunk
I pulled from git hub. (Awesome commenting in the code by the way).
Just wondering if there is some code floating around that might get
cookies+ssl working that I don't know about. Any advice is much
appreciated.
Cheers,
Nathan Keller
On Aug 3 2009, 12:55 pm, Mikeal Rogers <mikeal.rog...@gmail.com>
wrote:
> I've been working on a complete refactoring of the proxy code and
> there are a few things i think i should address on the list.
>
> The first is that the new code is much more flexible/reliable and will
> be easier to customize, add conditions and new apis to, and generally
> more readable.
>
> There are also a few externally facing APIs that will need to change.
> How we currently handle adding first_forward_domains and
> exclude_from_retry domains is some hack/magic that lets you set a
> domain string which will then be used forhttps:// and http://, in
> order to make this code somewhat readable and unify the API i'm
> deprecating that magic and only allowing full host strings, example: "http://www.addsite.com
> ". The name of the initial_forward_domains will also change to
> initial_forward_domains. The new APIs will, in addition to accepting
> regular strings, will accept regular expression strings. The reason we
> have to regular expressions strings instead of regex objects is
> because we plan on setting up a public blocklist that windmill will
> pull down and it will need to be JSON serializable.
>
> The name for adding proxy forwarding conditions will also change since
> there are now two APIs, one that accepts the environ dictionary (like
> the old API) and one that accepts a webenv request object (a new API).
>
> I've also removed a lot of the old globals, so the old ways of
> changing module level objects may go away if we can't find a clean way
> of making it reverse compatible.
>
> The new proxy should include most customizable response conditions
> (for customizing when a request in a retry loop is valid) proper cross-
> domaincookiehandling (something that almost worked in the old code