Mailing List Archive

The proxystuffs branch/5.8 Front End Proxy and other Engines.
In my never-ending efforts to deploy Catalyst in seemingly unusual
configurations, I've come across lacking support for X-Forwarded-Port
(or X-Forwarded-Host-Port) as well as X-Forwarded-Proto.

Andy pointed me to the "proxystuff" branch, but simply integrating
that (regardless of whether the tests pass) may cause other Engine's
to break. I'm not sure which, or even how they will break or how we
can detect breakage, so hopefully someone with fresh knowledge of the
proxystuff branch will be able to work with me on it.

Also, to snag the patch and apply to 5.8 could mean that we can bypass
some potential breakage, and at this point finalize a specific
"Extending Catalyst Engine's" API. In my searches here, I've found
that not only are there a huge variance in configuration methods, but
very few frameworks seem to document all the options thoroughly.

And, finally, for 6.0 I think it would be great to just add-in the
role support that you want. So your engine can be with FastCGI,
FrontEndProxy, etc.

Please pontificate. As it stands now I'm running a patched version of
Catalyst for an nginx+ssl proxy and I don't quite like that it isn't a
straight CPAN version. I should have continuing cycles to get
something written, tested and released this week as part of $work.

Thanks,
-Jay

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: The proxystuffs branch/5.8 Front End Proxy and other Engines. [ In reply to ]
On Mon, Nov 03, 2008 at 05:21:54PM -0700, J. Shirley wrote:
> In my never-ending efforts to deploy Catalyst in seemingly unusual
> configurations, I've come across lacking support for X-Forwarded-Port
> (or X-Forwarded-Host-Port) as well as X-Forwarded-Proto.
>
> Andy pointed me to the "proxystuff" branch, but simply integrating
> that (regardless of whether the tests pass) may cause other Engine's
> to break. I'm not sure which, or even how they will break or how we
> can detect breakage, so hopefully someone with fresh knowledge of the
> proxystuff branch will be able to work with me on it.
>
> Also, to snag the patch and apply to 5.8 could mean that we can bypass
> some potential breakage, and at this point finalize a specific
> "Extending Catalyst Engine's" API. In my searches here, I've found
> that not only are there a huge variance in configuration methods, but
> very few frameworks seem to document all the options thoroughly.
>
> And, finally, for 6.0 I think it would be great to just add-in the
> role support that you want. So your engine can be with FastCGI,
> FrontEndProxy, etc.

Hmm.

I think Andy put together an HTTP::Engine engine for experimentation. I sort
of wonder if that's the better place to look at persuading that sort of thing
to happen since we can switch to a C::E::HTTPEngine as the "standard" without
worrying about breaking anything else.

Thoughts, people?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: The proxystuffs branch/5.8 Front End Proxy and other Engines. [ In reply to ]
On Sat, Nov 15, 2008 at 8:40 AM, Matt S Trout <dbix-class@trout.me.uk> wrote:
> On Mon, Nov 03, 2008 at 05:21:54PM -0700, J. Shirley wrote:
>> In my never-ending efforts to deploy Catalyst in seemingly unusual
>> configurations, I've come across lacking support for X-Forwarded-Port
>> (or X-Forwarded-Host-Port) as well as X-Forwarded-Proto.
>>
>> Andy pointed me to the "proxystuff" branch, but simply integrating
>> that (regardless of whether the tests pass) may cause other Engine's
>> to break. I'm not sure which, or even how they will break or how we
>> can detect breakage, so hopefully someone with fresh knowledge of the
>> proxystuff branch will be able to work with me on it.
>>
>> Also, to snag the patch and apply to 5.8 could mean that we can bypass
>> some potential breakage, and at this point finalize a specific
>> "Extending Catalyst Engine's" API. In my searches here, I've found
>> that not only are there a huge variance in configuration methods, but
>> very few frameworks seem to document all the options thoroughly.
>>
>> And, finally, for 6.0 I think it would be great to just add-in the
>> role support that you want. So your engine can be with FastCGI,
>> FrontEndProxy, etc.
>
> Hmm.
>
> I think Andy put together an HTTP::Engine engine for experimentation. I sort
> of wonder if that's the better place to look at persuading that sort of thing
> to happen since we can switch to a C::E::HTTPEngine as the "standard" without
> worrying about breaking anything else.
>
> Thoughts, people?
>


Sounds reasonable to me, but I'd prefer to call it C::E::HTTP::Engine
to keep directly in sync with CPAN.

Yappo is the primary author on maint on HTTP::Engine, so I'll see what
I can do about getting the proxystuffs code into HTTP::Engine and then
I'll hack on C::E::HTTP::Engine in 5.8 to use it.

-J

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev