From judofyr at gmail.com  Wed Jul  2 20:52:41 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 3 Jul 2008 02:52:41 +0200
Subject: Getting rid of the route maker
In-Reply-To: <20080624150757.GN1424@beekeeper.hobix.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
Message-ID: <391a49da0807021752n4b2d12e6l9306c31b4372392@mail.gmail.com>

On Tue, Jun 24, 2008 at 5:07 PM, _why <why at whytheluckystiff.net> wrote:

> On Tue, Jun 24, 2008 at 01:05:54PM +0200, Magnus Holm wrote:
> > Man, that's way better than removing 135 bytes! I *love* the
> implementation!
>
> I have always wanted to use Method#to_proc in Camping.
>
> > Alright! What about releasing 2.0? I've closed a lot of tickets on the
> > tracker, and I don't think we need more for a 2.0. There is no point
> > of waiting anymore, IMO!
>
> I have two things left: I need to figure out if I want to merge
> zimbatm's Markaby patch.  And I'd like to go through Rack a bit more
> myself and see if I can cut down the work we're doing.  Hopefully
> today or tomorrow, though!
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

Come on, you lazy interrogative! Are your shoes too heavy? :-(

-- 
Magnus Holm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080703/327d6bfe/attachment.html>

From why at whytheluckystiff.net  Mon Jul  7 12:46:37 2008
From: why at whytheluckystiff.net (_why)
Date: Mon, 7 Jul 2008 11:46:37 -0500
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0807021752n4b2d12e6l9306c31b4372392@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
	<391a49da0807021752n4b2d12e6l9306c31b4372392@mail.gmail.com>
Message-ID: <20080707164636.GX7435@beekeeper.hobix.com>

On Thu, Jul 03, 2008 at 02:52:41AM +0200, Magnus Holm wrote:
> Come on, you lazy interrogative! Are your shoes too heavy? :-(

Bzzt!  (Drawing on backup camping power grids...)  Very sorry to be
bad about this.  Yeah, lots of Shoes stuff going on this week as
we're shooting for a July 31st release and there many bothersome bugs
to smash.

You've all done a lot of fanastic work and I say we keep working a
bit longer.  I just merged zimbatm's week-old patches and I think it
would be great if we could get more campers to mess with judofyr's
gems, as I think camping 2.0 will inspire some breakages.

Augusttime would be better for me, but let's talk about what you
guys want to do.

_why

From elefantstn at gmail.com  Thu Jul 10 11:01:09 2008
From: elefantstn at gmail.com (Joshua Miller)
Date: Thu, 10 Jul 2008 11:01:09 -0400
Subject: AR Sessions
Message-ID: <99d9e8df0807100801o64272090r41df7dbb2d9a3430@mail.gmail.com>

Hi all,

I have a little camping micro-blog that's working well with the cookie
session store, but falls over when I try to use the AR session store.
The changes I made were:

require 'camping/session' becomes require 'camping/ar/session'

module Blog; include Camping::Session; end becomes module Blog;
include Camping::ARSession; end

and I did the create_schema in Blog.create.

It set up the session table correctly, it adds a new row with a
session id and sets a cookie on the browser correctly, but it never
saves anything to the session state hash.  Do I need to do something
differently to make @state save itself?  Using the cookie session
store, changes are saved anytime I do something to @state, which is
how I would expect it to work.

I'm using the latest version from why's git repo with the default sqlite setup.

Thanks!
Josh

From kprojection at gmail.com  Fri Jul 11 01:06:02 2008
From: kprojection at gmail.com (Eric Mill)
Date: Fri, 11 Jul 2008 01:06:02 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
Message-ID: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>

Specifically, Dreamhost.  I'm trying to figure out how to get this to
work the standard dispatch.cgi or dispatch.fcgi setup.  I've been
using the instructions that Magnus sent out when he first announced
his plan for Camping 2.0, but they either no longer apply, or I'm an
edge case.

I've been pushing at it for a while, just to get it working on CGI,
and the problem seems to be that dispatch.cgi doesn't end in .ru!
Rack tries to "require 'dispatch.cgi'", which is no good.  Here's my
dispatch.cgi, with names changed to protect the innocent:

==================

#!/usr/bin/env rackup

ENV['GEM_PATH'] = '/path/to/local/gems'
ENV['GEM_HOME'] = '/path/to/local/gems'
ENV['FORCE_ROOT']=1.to_s

Dir.chdir '/path/to/app'

require 'app'
App::Models::Base.establish_connection :adapter => 'sqlite3',
:database => 'app.db'
App.create

run App

=============

And the error trace, as reported through apache's error logs:

/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- dispatch.cgi
(LoadError)
  from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
  from /usr/lib/ruby/gems/1.8/gems/rack-0.3.0/bin/rackup:92
  from /usr/bin/rackup:19:in `load'
  from /usr/bin/rackup:19
Premature end of script headers: dispatch.cgi

I'm still trying to get my head around the new Rack setup, the problem
might be some simple naivete on my part.  Anyone have any ideas how I
can push forward?

Thanks,
Eric

From kprojection at gmail.com  Fri Jul 11 01:33:45 2008
From: kprojection at gmail.com (Eric Mill)
Date: Fri, 11 Jul 2008 01:33:45 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
Message-ID: <c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>

Some progress: I put most of the code from dispatch.cgi into a
"config.ru", and dispatch.cgi now uses backticks to literally call
'/usr/bin/env rackup'.  This works, yet now calls to "/" redirect to
"/dispatch.cgi/" (this is truly the path in my browser location bar),
and it messes with my routing.

====  config.ru  ======
Dir.chdir '/path/to/app'
require 'app'
App::Models::Base.establish_connection :adapter => 'sqlite3',
:database => 'app.db'
App.create
run App

==== dispatch.cgi  ====
#!/usr/bin/ruby
ENV['GEM_PATH'] = '/path/to/gems'
ENV['GEM_HOME'] = '/path/to/gems'
puts `/usr/bin/env rackup`


And now I am definitely giving up for the night and sleeping.  Any ideas?

Thanks,
Eric

On Fri, Jul 11, 2008 at 1:06 AM, Eric Mill <kprojection at gmail.com> wrote:
> Specifically, Dreamhost.  I'm trying to figure out how to get this to
> work the standard dispatch.cgi or dispatch.fcgi setup.  I've been
> using the instructions that Magnus sent out when he first announced
> his plan for Camping 2.0, but they either no longer apply, or I'm an
> edge case.
>
> I've been pushing at it for a while, just to get it working on CGI,
> and the problem seems to be that dispatch.cgi doesn't end in .ru!
> Rack tries to "require 'dispatch.cgi'", which is no good.  Here's my
> dispatch.cgi, with names changed to protect the innocent:
>
> ==================
>
> #!/usr/bin/env rackup
>
> ENV['GEM_PATH'] = '/path/to/local/gems'
> ENV['GEM_HOME'] = '/path/to/local/gems'
> ENV['FORCE_ROOT']=1.to_s
>
> Dir.chdir '/path/to/app'
>
> require 'app'
> App::Models::Base.establish_connection :adapter => 'sqlite3',
> :database => 'app.db'
> App.create
>
> run App
>
> =============
>
> And the error trace, as reported through apache's error logs:
>
> /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require': no such file to load -- dispatch.cgi
> (LoadError)
>  from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
>  from /usr/lib/ruby/gems/1.8/gems/rack-0.3.0/bin/rackup:92
>  from /usr/bin/rackup:19:in `load'
>  from /usr/bin/rackup:19
> Premature end of script headers: dispatch.cgi
>
> I'm still trying to get my head around the new Rack setup, the problem
> might be some simple naivete on my part.  Anyone have any ideas how I
> can push forward?
>
> Thanks,
> Eric
>

From judofyr at gmail.com  Mon Jul 14 04:44:54 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 14 Jul 2008 10:44:54 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
Message-ID: <391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>

What about dropping the idea of config.ru and just create a dispatch.cgi
like this?

    #!/usr/bin/env ruby
    require 'app'
    Rack::Handler::CGI.run(App)

On Fri, Jul 11, 2008 at 7:33 AM, Eric Mill <kprojection at gmail.com> wrote:

> Some progress: I put most of the code from dispatch.cgi into a
> "config.ru", and dispatch.cgi now uses backticks to literally call
> '/usr/bin/env rackup'.  This works, yet now calls to "/" redirect to
> "/dispatch.cgi/" (this is truly the path in my browser location bar),
> and it messes with my routing.
>
> ====  config.ru  ======
> Dir.chdir '/path/to/app'
> require 'app'
> App::Models::Base.establish_connection :adapter => 'sqlite3',
> :database => 'app.db'
> App.create
> run App
>
> ==== dispatch.cgi  ====
> #!/usr/bin/ruby
> ENV['GEM_PATH'] = '/path/to/gems'
> ENV['GEM_HOME'] = '/path/to/gems'
> puts `/usr/bin/env rackup`
>
>
> And now I am definitely giving up for the night and sleeping.  Any ideas?
>
> Thanks,
> Eric
>
> On Fri, Jul 11, 2008 at 1:06 AM, Eric Mill <kprojection at gmail.com> wrote:
> > Specifically, Dreamhost.  I'm trying to figure out how to get this to
> > work the standard dispatch.cgi or dispatch.fcgi setup.  I've been
> > using the instructions that Magnus sent out when he first announced
> > his plan for Camping 2.0, but they either no longer apply, or I'm an
> > edge case.
> >
> > I've been pushing at it for a while, just to get it working on CGI,
> > and the problem seems to be that dispatch.cgi doesn't end in .ru!
> > Rack tries to "require 'dispatch.cgi'", which is no good.  Here's my
> > dispatch.cgi, with names changed to protect the innocent:
> >
> > ==================
> >
> > #!/usr/bin/env rackup
> >
> > ENV['GEM_PATH'] = '/path/to/local/gems'
> > ENV['GEM_HOME'] = '/path/to/local/gems'
> > ENV['FORCE_ROOT']=1.to_s
> >
> > Dir.chdir '/path/to/app'
> >
> > require 'app'
> > App::Models::Base.establish_connection :adapter => 'sqlite3',
> > :database => 'app.db'
> > App.create
> >
> > run App
> >
> > =============
> >
> > And the error trace, as reported through apache's error logs:
> >
> > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
> > `gem_original_require': no such file to load -- dispatch.cgi
> > (LoadError)
> >  from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
> >  from /usr/lib/ruby/gems/1.8/gems/rack-0.3.0/bin/rackup:92
> >  from /usr/bin/rackup:19:in `load'
> >  from /usr/bin/rackup:19
> > Premature end of script headers: dispatch.cgi
> >
> > I'm still trying to get my head around the new Rack setup, the problem
> > might be some simple naivete on my part.  Anyone have any ideas how I
> > can push forward?
> >
> > Thanks,
> > Eric
> >
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080714/3982007c/attachment.html>

From kprojection at gmail.com  Mon Jul 14 08:37:41 2008
From: kprojection at gmail.com (Eric Mill)
Date: Mon, 14 Jul 2008 08:37:41 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
Message-ID: <c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>

Actually, that is what I'm doing now, and I'm still seeing the same
behavior -- redirects preface the URL with "/dispatch.cgi/", and the
Camping cookies are valid under path "/dispatch.cgi/".  I have another
camping app on the same account, that uses Camping 1.5.180, and when I
first tried it under CGI I didn't get this behavior.  I'm using the
same .htaccess, too.

-- Eric

On Mon, Jul 14, 2008 at 4:44 AM, Magnus Holm <judofyr at gmail.com> wrote:
> What about dropping the idea of config.ru and just create a dispatch.cgi
> like this?
>
>     #!/usr/bin/env ruby
>     require 'app'
>     Rack::Handler::CGI.run(App)
>
> On Fri, Jul 11, 2008 at 7:33 AM, Eric Mill <kprojection at gmail.com> wrote:
>>
>> Some progress: I put most of the code from dispatch.cgi into a
>> "config.ru", and dispatch.cgi now uses backticks to literally call
>> '/usr/bin/env rackup'.  This works, yet now calls to "/" redirect to
>> "/dispatch.cgi/" (this is truly the path in my browser location bar),
>> and it messes with my routing.
>>
>> ====  config.ru  ======
>> Dir.chdir '/path/to/app'
>> require 'app'
>> App::Models::Base.establish_connection :adapter => 'sqlite3',
>> :database => 'app.db'
>> App.create
>> run App
>>
>> ==== dispatch.cgi  ====
>> #!/usr/bin/ruby
>> ENV['GEM_PATH'] = '/path/to/gems'
>> ENV['GEM_HOME'] = '/path/to/gems'
>> puts `/usr/bin/env rackup`
>>
>>
>> And now I am definitely giving up for the night and sleeping.  Any ideas?
>>
>> Thanks,
>> Eric
>>
>> On Fri, Jul 11, 2008 at 1:06 AM, Eric Mill <kprojection at gmail.com> wrote:
>> > Specifically, Dreamhost.  I'm trying to figure out how to get this to
>> > work the standard dispatch.cgi or dispatch.fcgi setup.  I've been
>> > using the instructions that Magnus sent out when he first announced
>> > his plan for Camping 2.0, but they either no longer apply, or I'm an
>> > edge case.
>> >
>> > I've been pushing at it for a while, just to get it working on CGI,
>> > and the problem seems to be that dispatch.cgi doesn't end in .ru!
>> > Rack tries to "require 'dispatch.cgi'", which is no good.  Here's my
>> > dispatch.cgi, with names changed to protect the innocent:
>> >
>> > ==================
>> >
>> > #!/usr/bin/env rackup
>> >
>> > ENV['GEM_PATH'] = '/path/to/local/gems'
>> > ENV['GEM_HOME'] = '/path/to/local/gems'
>> > ENV['FORCE_ROOT']=1.to_s
>> >
>> > Dir.chdir '/path/to/app'
>> >
>> > require 'app'
>> > App::Models::Base.establish_connection :adapter => 'sqlite3',
>> > :database => 'app.db'
>> > App.create
>> >
>> > run App
>> >
>> > =============
>> >
>> > And the error trace, as reported through apache's error logs:
>> >
>> > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
>> > `gem_original_require': no such file to load -- dispatch.cgi
>> > (LoadError)
>> >  from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
>> > `require'
>> >  from /usr/lib/ruby/gems/1.8/gems/rack-0.3.0/bin/rackup:92
>> >  from /usr/bin/rackup:19:in `load'
>> >  from /usr/bin/rackup:19
>> > Premature end of script headers: dispatch.cgi
>> >
>> > I'm still trying to get my head around the new Rack setup, the problem
>> > might be some simple naivete on my part.  Anyone have any ideas how I
>> > can push forward?
>> >
>> > Thanks,
>> > Eric
>> >
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From blueberry at creativepony.com  Mon Jul 14 08:59:49 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 14 Jul 2008 22:59:49 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
Message-ID: <9490A641-41BB-4CF5-92BA-5E6F4E187043@creativepony.com>

Could you show us the .htaccess please? :)

From blueberry at creativepony.com  Mon Jul 14 09:14:19 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 14 Jul 2008 23:14:19 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
Message-ID: <DFEC0D9B-49A6-4475-B388-0F73F5436126@creativepony.com>

Also, is it possible that you could simply rename dispatch.cgi to  
something like 'appname' and use htaccess to grant that file cgi  
execution type permissions? Or does this need to be on the root of a  
domain?

From blueberry at creativepony.com  Mon Jul 14 09:16:30 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 14 Jul 2008 23:16:30 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
Message-ID: <405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>

can you please try adding to htaccess SetEnv SCRIPT_NAME /path/to/app

Assuming your dispatch is in /path/to/app/dispatch.cgi

Let us know what happens!

From blueberry at creativepony.com  Mon Jul 14 09:22:08 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 14 Jul 2008 23:22:08 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
Message-ID: <F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>

No wait, this is even better, at the end of your RewriteRule, put:

[env=SCRIPT_NAME:/path/to/app]

Let us know what happens!

From kprojection at gmail.com  Mon Jul 14 12:14:17 2008
From: kprojection at gmail.com (Eric Mill)
Date: Mon, 14 Jul 2008 12:14:17 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
Message-ID: <c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>

I'm not able to get this working, I can't seem to affect the
environment, either using the SetEnv approach, or by including that at
the end of RewriteRule.  How does Camping use the env in forming its
understanding of its base URI?

Forming URLs using the "R" method does not pre-pend "/dispatch.cgi/",
but calling Redirect does.  And as I said earlier, session cookies are
set for the path "/dispatch.cgi/".

I'm continuing to investigate...

-- Eric

On Mon, Jul 14, 2008 at 9:22 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> No wait, this is even better, at the end of your RewriteRule, put:
>
> [env=SCRIPT_NAME:/path/to/app]
>
> Let us know what happens!
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Mon Jul 14 12:58:38 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 14 Jul 2008 18:58:38 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
Message-ID: <391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>

R won't add the root path (it's a feature, not a bug).

Camping (and Rack) assumes that SCRIPT_NAME will contain the root path. If
you can't change it in Apache, I guess you could add a middleware:

  class ScriptNameFixer
    def initialize(app)
      @app = app
    end

    def call(env)
      env["SCRIPT_NAME"] = "/your/path"
      @app.call(env)
    end
  end

Could you post your .htaccess? There must be a way to do this properly in
Apache!

On Mon, Jul 14, 2008 at 6:14 PM, Eric Mill <kprojection at gmail.com> wrote:

> I'm not able to get this working, I can't seem to affect the
> environment, either using the SetEnv approach, or by including that at
> the end of RewriteRule.  How does Camping use the env in forming its
> understanding of its base URI?
>
> Forming URLs using the "R" method does not pre-pend "/dispatch.cgi/",
> but calling Redirect does.  And as I said earlier, session cookies are
> set for the path "/dispatch.cgi/".
>
> I'm continuing to investigate...
>
> -- Eric
>
> On Mon, Jul 14, 2008 at 9:22 AM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
> > No wait, this is even better, at the end of your RewriteRule, put:
> >
> > [env=SCRIPT_NAME:/path/to/app]
> >
> > Let us know what happens!
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080714/ce63a64b/attachment.html>

From blueberry at creativepony.com  Mon Jul 14 18:58:43 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 15 Jul 2008 08:58:43 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
Message-ID: <5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>

I really do think we should build in the SCRIPT_URL || SCRIPT_NAME  
thingo. This is going to be a relatively common situation. Totally  
worth the bytes.

From julian.tarkhanov at gmail.com  Mon Jul 14 19:20:28 2008
From: julian.tarkhanov at gmail.com (Julik Tarkhanov)
Date: Tue, 15 Jul 2008 01:20:28 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
Message-ID: <C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>


On Jul 15, 2008, at 12:58 AM, Bluebie, Jenna wrote:

> I really do think we should build in the SCRIPT_URL || SCRIPT_NAME  
> thingo. This is going to be a relatively common situation. Totally  
> worth the bytes.

You might, but this is a can of worms. See, right now for example, if  
you need to mount Camping on all root URLs but you still
want to handle static files via frontent web servers you have a  
problem, because an FCGI mount "swallows" all URLs inside it.

I didn't manage (with the current setup, not with Camping 2) to both  
mount a rooted app and handle the files bypassing it, exactly because
in FCGI-parlance the "mount" of the FCGI dispatcher is the SCRIPT_NAME.

Dunno about "thingos" but a clean solution would be welcome (also  
Rack currently advises the user to _write_ a hack for Lighttpd
for broken SCRIPT_NAME - can't even tell how silly that is).

From blueberry at creativepony.com  Mon Jul 14 19:40:33 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 15 Jul 2008 09:40:33 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807102233n5e6d32fdp31aba909e056ed3a@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
Message-ID: <A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>

We are talking about cgi here, not fast cgi. Specifically CGI's  
interactions with mod_rewrite in apache.

From kprojection at gmail.com  Wed Jul 16 11:07:00 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 11:07:00 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
Message-ID: <c658be6b0807160807q4982f2b9qf412c30caf1f8eeb@mail.gmail.com>

My .htaccess is pretty basic, I think:

AddHandler fastcgi-script .fcgi
Options +FollowSymLinks +ExecCGI

RewriteEngine On

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]

Anything out of the ordinary there?

-- Eric

On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> We are talking about cgi here, not fast cgi. Specifically CGI's interactions
> with mod_rewrite in apache.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From kprojection at gmail.com  Wed Jul 16 11:07:50 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 11:07:50 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<391a49da0807140144g5815f81cwb5065f4f0da974d8@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
Message-ID: <c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>

Bluebie -- I tried doing this with FastCGI with the same settings
(changed .htaccess to point to dispatch.fcgi, changed dispatch file to
use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
will also suffer from these bugs.

-- Eric

On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> We are talking about cgi here, not fast cgi. Specifically CGI's interactions
> with mod_rewrite in apache.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Wed Jul 16 17:08:18 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 16 Jul 2008 23:08:18 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807140537u4113f644m4c99f36bc17bafb9@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
Message-ID: <391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>

This "bug" is actually Apache's fault. The problem occurs when you use
mod_rewrite to hide that you're using dispatch.cgi. When you use
"RewriteRule ^(.*)$ dispatch.cgi" the following happens:

* SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
which gets ran)
* REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
* PATH_INFO is emptied

I've also tested this on 1.5 and it has the same problem. However, if
you use server/fastcgi.rb (not Rack as I've been testing with) you can
set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
PATH_INFO using REQUEST_URI, which will (partly) solve the problem.

Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:

* Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
need to drop to slash).
* Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
(http://pastie.org/235062)

This isn't really our problem, but rather Apache (which should be able
to alias CGI-scripts with the correct headers). It probably won't
happen, so I guess we have to add some nasty hacks into Rack.

I haven't tried this on any other servers (LightTPD/Nginx), but as
long as there is no URL-rewriting (I know LightTPD can do it with
FastCGI) it's probably no problem (maybe not even with, if it's smart
enough).

Here is a simple app which shows @env (and works on both 1.5 and 2.0):
http://pastie.org/235078. It would be great if you could test it on
different setups and see which requires special treatment. Check out
the Rack-spec for how the variables should be set:
http://rack.rubyforge.org/doc/files/SPEC.html

On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>
> Bluebie -- I tried doing this with FastCGI with the same settings
> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
> will also suffer from these bugs.
>
> -- Eric
>
> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
> > with mod_rewrite in apache.
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list



--
Magnus Holm

From kprojection at gmail.com  Wed Jul 16 17:28:57 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 17:28:57 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<405C6174-2EFF-4A92-AE39-2854DAB92CE7@creativepony.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
Message-ID: <c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>

Magnus, this is terrific information, thank you for looking into this.

I'm trying to follow your example - you use ApacheFixer to make a
"TestingFixed" class, but never use that class anywhere else.  Do you
mean for the lines in dispatch.* to use "TestingFixed" instead of
"Testing"?

I'm trying to use this to resolve my problems as we speak,
Eric

On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
> This "bug" is actually Apache's fault. The problem occurs when you use
> mod_rewrite to hide that you're using dispatch.cgi. When you use
> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>
> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
> which gets ran)
> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
> * PATH_INFO is emptied
>
> I've also tested this on 1.5 and it has the same problem. However, if
> you use server/fastcgi.rb (not Rack as I've been testing with) you can
> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>
> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>
> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
> need to drop to slash).
> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
> (http://pastie.org/235062)
>
> This isn't really our problem, but rather Apache (which should be able
> to alias CGI-scripts with the correct headers). It probably won't
> happen, so I guess we have to add some nasty hacks into Rack.
>
> I haven't tried this on any other servers (LightTPD/Nginx), but as
> long as there is no URL-rewriting (I know LightTPD can do it with
> FastCGI) it's probably no problem (maybe not even with, if it's smart
> enough).
>
> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
> http://pastie.org/235078. It would be great if you could test it on
> different setups and see which requires special treatment. Check out
> the Rack-spec for how the variables should be set:
> http://rack.rubyforge.org/doc/files/SPEC.html
>
> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>
>> Bluebie -- I tried doing this with FastCGI with the same settings
>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>> will also suffer from these bugs.
>>
>> -- Eric
>>
>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>> <blueberry at creativepony.com> wrote:
>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>> > with mod_rewrite in apache.
>> > _______________________________________________
>> > Camping-list mailing list
>> > Camping-list at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/camping-list
>> >
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Wed Jul 16 17:31:15 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 16 Jul 2008 23:31:15 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<F2E64245-10D1-4468-8490-B9C97DB8C184@creativepony.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
Message-ID: <391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>

Simply replace Testing with TestingFixed in dispatch.cgi:11 and
dispatch.fcgi:13 to see the diffenrence :-)

On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
> Magnus, this is terrific information, thank you for looking into this.
>
> I'm trying to follow your example - you use ApacheFixer to make a
> "TestingFixed" class, but never use that class anywhere else.  Do you
> mean for the lines in dispatch.* to use "TestingFixed" instead of
> "Testing"?
>
> I'm trying to use this to resolve my problems as we speak,
> Eric
>
> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>> This "bug" is actually Apache's fault. The problem occurs when you use
>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>
>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>> which gets ran)
>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>> * PATH_INFO is emptied
>>
>> I've also tested this on 1.5 and it has the same problem. However, if
>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>
>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>
>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>> need to drop to slash).
>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>> (http://pastie.org/235062)
>>
>> This isn't really our problem, but rather Apache (which should be able
>> to alias CGI-scripts with the correct headers). It probably won't
>> happen, so I guess we have to add some nasty hacks into Rack.
>>
>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>> long as there is no URL-rewriting (I know LightTPD can do it with
>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>> enough).
>>
>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>> http://pastie.org/235078. It would be great if you could test it on
>> different setups and see which requires special treatment. Check out
>> the Rack-spec for how the variables should be set:
>> http://rack.rubyforge.org/doc/files/SPEC.html
>>
>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>
>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>> will also suffer from these bugs.
>>>
>>> -- Eric
>>>
>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>> <blueberry at creativepony.com> wrote:
>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>> > with mod_rewrite in apache.
>>> > _______________________________________________
>>> > Camping-list mailing list
>>> > Camping-list at rubyforge.org
>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>> >
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> --
>> Magnus Holm
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From kprojection at gmail.com  Wed Jul 16 17:40:13 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 17:40:13 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
Message-ID: <c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>

Unfortunately this isn't working.  I'm checking my ENV and
REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
to try to figure out an alternative.

Right now, requests to "/" go to a Camping error page which says
"/index.html not found!"  and requests to "/login" (which should go to
a different controller) says "/login.html not found!".  PATH_INFO has
been set to "/login.html" in this case.

I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
this has the same effect as using the REDIRECT_SCRIPT_NAME approach.

Continuing to investigate,
Eric

On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
> dispatch.fcgi:13 to see the diffenrence :-)
>
> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>> Magnus, this is terrific information, thank you for looking into this.
>>
>> I'm trying to follow your example - you use ApacheFixer to make a
>> "TestingFixed" class, but never use that class anywhere else.  Do you
>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>> "Testing"?
>>
>> I'm trying to use this to resolve my problems as we speak,
>> Eric
>>
>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>
>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>> which gets ran)
>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>> * PATH_INFO is emptied
>>>
>>> I've also tested this on 1.5 and it has the same problem. However, if
>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>
>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>
>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>> need to drop to slash).
>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>> (http://pastie.org/235062)
>>>
>>> This isn't really our problem, but rather Apache (which should be able
>>> to alias CGI-scripts with the correct headers). It probably won't
>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>
>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>> enough).
>>>
>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>> http://pastie.org/235078. It would be great if you could test it on
>>> different setups and see which requires special treatment. Check out
>>> the Rack-spec for how the variables should be set:
>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>
>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>
>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>> will also suffer from these bugs.
>>>>
>>>> -- Eric
>>>>
>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>> <blueberry at creativepony.com> wrote:
>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>> > with mod_rewrite in apache.
>>>> > _______________________________________________
>>>> > Camping-list mailing list
>>>> > Camping-list at rubyforge.org
>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>> >
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> --
>>> Magnus Holm
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From kprojection at gmail.com  Wed Jul 16 17:51:53 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 17:51:53 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
Message-ID: <c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>

Also worth noting is that PATH_INFO isn't emptied - it's set to "/" or
"/login", the correct request path.

-- Eric

On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill <kprojection at gmail.com> wrote:
> Unfortunately this isn't working.  I'm checking my ENV and
> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
> to try to figure out an alternative.
>
> Right now, requests to "/" go to a Camping error page which says
> "/index.html not found!"  and requests to "/login" (which should go to
> a different controller) says "/login.html not found!".  PATH_INFO has
> been set to "/login.html" in this case.
>
> I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
> this has the same effect as using the REDIRECT_SCRIPT_NAME approach.
>
> Continuing to investigate,
> Eric
>
> On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
>> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
>> dispatch.fcgi:13 to see the diffenrence :-)
>>
>> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>>> Magnus, this is terrific information, thank you for looking into this.
>>>
>>> I'm trying to follow your example - you use ApacheFixer to make a
>>> "TestingFixed" class, but never use that class anywhere else.  Do you
>>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>>> "Testing"?
>>>
>>> I'm trying to use this to resolve my problems as we speak,
>>> Eric
>>>
>>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>>
>>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>>> which gets ran)
>>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>>> * PATH_INFO is emptied
>>>>
>>>> I've also tested this on 1.5 and it has the same problem. However, if
>>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>>
>>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>>
>>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>>> need to drop to slash).
>>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>>> (http://pastie.org/235062)
>>>>
>>>> This isn't really our problem, but rather Apache (which should be able
>>>> to alias CGI-scripts with the correct headers). It probably won't
>>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>>
>>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>>> enough).
>>>>
>>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>>> http://pastie.org/235078. It would be great if you could test it on
>>>> different setups and see which requires special treatment. Check out
>>>> the Rack-spec for how the variables should be set:
>>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>>
>>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>
>>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>>> will also suffer from these bugs.
>>>>>
>>>>> -- Eric
>>>>>
>>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>>> <blueberry at creativepony.com> wrote:
>>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>>> > with mod_rewrite in apache.
>>>>> > _______________________________________________
>>>>> > Camping-list mailing list
>>>>> > Camping-list at rubyforge.org
>>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>>> >
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> --
>>>> Magnus Holm
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>>
>> --
>> Magnus Holm
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>

From julian.tarkhanov at gmail.com  Wed Jul 16 18:03:12 2008
From: julian.tarkhanov at gmail.com (Julian Tarkhanov)
Date: Thu, 17 Jul 2008 00:03:12 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807140914m22457accvf5d1f3227667b74c@mail.gmail.com>
	<391a49da0807140958h7981e765yc02f7e1b0d77c1ff@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
Message-ID: <42B58AAB-88E9-47AF-B897-8ECA9BC156BF@gmail.com>

On 16 jul 2008, at 23:40, Eric Mill wrote:

> Unfortunately this isn't working.  I'm checking my ENV and
> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
> to try to figure out an alternative.

Rails resolves this somehow, they mount dispatch.fcgi as / 
dispatch.fcgi and use it as rewrite target.

From kprojection at gmail.com  Wed Jul 16 18:08:53 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 18:08:53 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<5EA7A235-520E-48C7-A73A-CFB369EED71A@creativepony.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
	<c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
Message-ID: <c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>

I think I've got it working, with this as the 'fixer' call:

  def call(env)
    env['SCRIPT_NAME'] = '/'
    env['PATH_INFO'] = env['REDIRECT_URL']
    @app.call(env)
  end

I think you might have meant REDIRECT_URL and not REDIRECT_SCRIPT_NAME?

Thank you Magnus!

-- Eric

On Wed, Jul 16, 2008 at 5:51 PM, Eric Mill <kprojection at gmail.com> wrote:
> Also worth noting is that PATH_INFO isn't emptied - it's set to "/" or
> "/login", the correct request path.
>
> -- Eric
>
> On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill <kprojection at gmail.com> wrote:
>> Unfortunately this isn't working.  I'm checking my ENV and
>> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
>> to try to figure out an alternative.
>>
>> Right now, requests to "/" go to a Camping error page which says
>> "/index.html not found!"  and requests to "/login" (which should go to
>> a different controller) says "/login.html not found!".  PATH_INFO has
>> been set to "/login.html" in this case.
>>
>> I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
>> this has the same effect as using the REDIRECT_SCRIPT_NAME approach.
>>
>> Continuing to investigate,
>> Eric
>>
>> On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
>>> dispatch.fcgi:13 to see the diffenrence :-)
>>>
>>> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>> Magnus, this is terrific information, thank you for looking into this.
>>>>
>>>> I'm trying to follow your example - you use ApacheFixer to make a
>>>> "TestingFixed" class, but never use that class anywhere else.  Do you
>>>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>>>> "Testing"?
>>>>
>>>> I'm trying to use this to resolve my problems as we speak,
>>>> Eric
>>>>
>>>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>>>
>>>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>>>> which gets ran)
>>>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>>>> * PATH_INFO is emptied
>>>>>
>>>>> I've also tested this on 1.5 and it has the same problem. However, if
>>>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>>>
>>>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>>>
>>>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>>>> need to drop to slash).
>>>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>>>> (http://pastie.org/235062)
>>>>>
>>>>> This isn't really our problem, but rather Apache (which should be able
>>>>> to alias CGI-scripts with the correct headers). It probably won't
>>>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>>>
>>>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>>>> enough).
>>>>>
>>>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>>>> http://pastie.org/235078. It would be great if you could test it on
>>>>> different setups and see which requires special treatment. Check out
>>>>> the Rack-spec for how the variables should be set:
>>>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>>>
>>>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>>
>>>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>>>> will also suffer from these bugs.
>>>>>>
>>>>>> -- Eric
>>>>>>
>>>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>>>> <blueberry at creativepony.com> wrote:
>>>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>>>> > with mod_rewrite in apache.
>>>>>> > _______________________________________________
>>>>>> > Camping-list mailing list
>>>>>> > Camping-list at rubyforge.org
>>>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>>>> >
>>>>>> _______________________________________________
>>>>>> Camping-list mailing list
>>>>>> Camping-list at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Magnus Holm
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>
>>>
>>>
>>> --
>>> Magnus Holm
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>

From kprojection at gmail.com  Wed Jul 16 18:13:08 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 18:13:08 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<C1EBE4F1-3538-4270-B319-48F1B06003D6@gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
	<c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
	<c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>
Message-ID: <c658be6b0807161513h123fa51cn38aa01ecd6a7975a@mail.gmail.com>

The 500-handling I'm used to appears to be gone.  What's the best approach here?

-- Eric

On Wed, Jul 16, 2008 at 6:08 PM, Eric Mill <kprojection at gmail.com> wrote:
> I think I've got it working, with this as the 'fixer' call:
>
>  def call(env)
>    env['SCRIPT_NAME'] = '/'
>    env['PATH_INFO'] = env['REDIRECT_URL']
>    @app.call(env)
>  end
>
> I think you might have meant REDIRECT_URL and not REDIRECT_SCRIPT_NAME?
>
> Thank you Magnus!
>
> -- Eric
>
> On Wed, Jul 16, 2008 at 5:51 PM, Eric Mill <kprojection at gmail.com> wrote:
>> Also worth noting is that PATH_INFO isn't emptied - it's set to "/" or
>> "/login", the correct request path.
>>
>> -- Eric
>>
>> On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill <kprojection at gmail.com> wrote:
>>> Unfortunately this isn't working.  I'm checking my ENV and
>>> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
>>> to try to figure out an alternative.
>>>
>>> Right now, requests to "/" go to a Camping error page which says
>>> "/index.html not found!"  and requests to "/login" (which should go to
>>> a different controller) says "/login.html not found!".  PATH_INFO has
>>> been set to "/login.html" in this case.
>>>
>>> I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
>>> this has the same effect as using the REDIRECT_SCRIPT_NAME approach.
>>>
>>> Continuing to investigate,
>>> Eric
>>>
>>> On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
>>>> dispatch.fcgi:13 to see the diffenrence :-)
>>>>
>>>> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>> Magnus, this is terrific information, thank you for looking into this.
>>>>>
>>>>> I'm trying to follow your example - you use ApacheFixer to make a
>>>>> "TestingFixed" class, but never use that class anywhere else.  Do you
>>>>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>>>>> "Testing"?
>>>>>
>>>>> I'm trying to use this to resolve my problems as we speak,
>>>>> Eric
>>>>>
>>>>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>>>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>>>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>>>>
>>>>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>>>>> which gets ran)
>>>>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>>>>> * PATH_INFO is emptied
>>>>>>
>>>>>> I've also tested this on 1.5 and it has the same problem. However, if
>>>>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>>>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>>>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>>>>
>>>>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>>>>
>>>>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>>>>> need to drop to slash).
>>>>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>>>>> (http://pastie.org/235062)
>>>>>>
>>>>>> This isn't really our problem, but rather Apache (which should be able
>>>>>> to alias CGI-scripts with the correct headers). It probably won't
>>>>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>>>>
>>>>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>>>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>>>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>>>>> enough).
>>>>>>
>>>>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>>>>> http://pastie.org/235078. It would be great if you could test it on
>>>>>> different setups and see which requires special treatment. Check out
>>>>>> the Rack-spec for how the variables should be set:
>>>>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>>>>
>>>>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>>>
>>>>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>>>>> will also suffer from these bugs.
>>>>>>>
>>>>>>> -- Eric
>>>>>>>
>>>>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>>>>> <blueberry at creativepony.com> wrote:
>>>>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>>>>> > with mod_rewrite in apache.
>>>>>>> > _______________________________________________
>>>>>>> > Camping-list mailing list
>>>>>>> > Camping-list at rubyforge.org
>>>>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> Camping-list mailing list
>>>>>>> Camping-list at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Magnus Holm
>>>>>> _______________________________________________
>>>>>> Camping-list mailing list
>>>>>> Camping-list at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Magnus Holm
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>
>>
>

From kprojection at gmail.com  Wed Jul 16 20:08:14 2008
From: kprojection at gmail.com (Eric Mill)
Date: Wed, 16 Jul 2008 20:08:14 -0400
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161513h123fa51cn38aa01ecd6a7975a@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
	<c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
	<c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>
	<c658be6b0807161513h123fa51cn38aa01ecd6a7975a@mail.gmail.com>
Message-ID: <c658be6b0807161708h30d378eem327456cc259645e2@mail.gmail.com>

OK, I am good to go, working CGI and FastCGI .htaccess and dispatch.*
files written.  I changed REDIRECT_URI to REQUEST_URI.

For CGI:
* dispatch.cgi: http://pastie.org/235313
* .htaccess for CGI: http://pastie.org/235315

For FastCGI, based on the above:
* in dispatch.cgi, change Rack::Handler::CGI.run to be
Rack::Handler::FastCGI.run
* in .htaccess change dispatch.cgi to be dispatch.fcgi

Awesome.  Thanks for everyone's help.  Especially Magnus and Jenna,
you two rule.

This seems like a good candidate for the github Camping wiki -- do
people even know that thing exists, is it worth it?  Or should I just
add it to the Camping wiki on why's site?

-- Eric

On Wed, Jul 16, 2008 at 6:13 PM, Eric Mill <kprojection at gmail.com> wrote:
> The 500-handling I'm used to appears to be gone.  What's the best approach here?
>
> -- Eric
>
> On Wed, Jul 16, 2008 at 6:08 PM, Eric Mill <kprojection at gmail.com> wrote:
>> I think I've got it working, with this as the 'fixer' call:
>>
>>  def call(env)
>>    env['SCRIPT_NAME'] = '/'
>>    env['PATH_INFO'] = env['REDIRECT_URL']
>>    @app.call(env)
>>  end
>>
>> I think you might have meant REDIRECT_URL and not REDIRECT_SCRIPT_NAME?
>>
>> Thank you Magnus!
>>
>> -- Eric
>>
>> On Wed, Jul 16, 2008 at 5:51 PM, Eric Mill <kprojection at gmail.com> wrote:
>>> Also worth noting is that PATH_INFO isn't emptied - it's set to "/" or
>>> "/login", the correct request path.
>>>
>>> -- Eric
>>>
>>> On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>> Unfortunately this isn't working.  I'm checking my ENV and
>>>> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
>>>> to try to figure out an alternative.
>>>>
>>>> Right now, requests to "/" go to a Camping error page which says
>>>> "/index.html not found!"  and requests to "/login" (which should go to
>>>> a different controller) says "/login.html not found!".  PATH_INFO has
>>>> been set to "/login.html" in this case.
>>>>
>>>> I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
>>>> this has the same effect as using the REDIRECT_SCRIPT_NAME approach.
>>>>
>>>> Continuing to investigate,
>>>> Eric
>>>>
>>>> On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
>>>>> dispatch.fcgi:13 to see the diffenrence :-)
>>>>>
>>>>> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>> Magnus, this is terrific information, thank you for looking into this.
>>>>>>
>>>>>> I'm trying to follow your example - you use ApacheFixer to make a
>>>>>> "TestingFixed" class, but never use that class anywhere else.  Do you
>>>>>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>>>>>> "Testing"?
>>>>>>
>>>>>> I'm trying to use this to resolve my problems as we speak,
>>>>>> Eric
>>>>>>
>>>>>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>>>>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>>>>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>>>>>
>>>>>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>>>>>> which gets ran)
>>>>>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>>>>>> * PATH_INFO is emptied
>>>>>>>
>>>>>>> I've also tested this on 1.5 and it has the same problem. However, if
>>>>>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>>>>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>>>>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>>>>>
>>>>>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>>>>>
>>>>>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>>>>>> need to drop to slash).
>>>>>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>>>>>> (http://pastie.org/235062)
>>>>>>>
>>>>>>> This isn't really our problem, but rather Apache (which should be able
>>>>>>> to alias CGI-scripts with the correct headers). It probably won't
>>>>>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>>>>>
>>>>>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>>>>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>>>>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>>>>>> enough).
>>>>>>>
>>>>>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>>>>>> http://pastie.org/235078. It would be great if you could test it on
>>>>>>> different setups and see which requires special treatment. Check out
>>>>>>> the Rack-spec for how the variables should be set:
>>>>>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>>>>>
>>>>>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>>>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>>>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>>>>>> will also suffer from these bugs.
>>>>>>>>
>>>>>>>> -- Eric
>>>>>>>>
>>>>>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>>>>>> <blueberry at creativepony.com> wrote:
>>>>>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>>>>>> > with mod_rewrite in apache.
>>>>>>>> > _______________________________________________
>>>>>>>> > Camping-list mailing list
>>>>>>>> > Camping-list at rubyforge.org
>>>>>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> Camping-list mailing list
>>>>>>>> Camping-list at rubyforge.org
>>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Magnus Holm
>>>>>>> _______________________________________________
>>>>>>> Camping-list mailing list
>>>>>>> Camping-list at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Camping-list mailing list
>>>>>> Camping-list at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Magnus Holm
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>>
>>>
>>
>

From blueberry at creativepony.com  Wed Jul 16 21:26:03 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 17 Jul 2008 11:26:03 +1000
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161708h30d378eem327456cc259645e2@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<A75B1A81-2A47-449C-A8B2-159C6ABA4029@creativepony.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
	<c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
	<c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>
	<c658be6b0807161513h123fa51cn38aa01ecd6a7975a@mail.gmail.com>
	<c658be6b0807161708h30d378eem327456cc259645e2@mail.gmail.com>
Message-ID: <885477A8-8455-4933-991F-C75D1C81E435@creativepony.com>

Just add it :)

From judofyr at gmail.com  Fri Jul 18 20:52:24 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 19 Jul 2008 02:52:24 +0200
Subject: Troubleshooting: Camping 2.0 on CGI on a shared host
In-Reply-To: <c658be6b0807161708h30d378eem327456cc259645e2@mail.gmail.com>
References: <c658be6b0807102206p103f9daeo57143d0d4725e9d4@mail.gmail.com>
	<c658be6b0807160807g7a978751hfd3782cf29d814b9@mail.gmail.com>
	<391a49da0807161408i1d0b2e3fqc101a2fa254cf869@mail.gmail.com>
	<c658be6b0807161428l7ecf94d5mfde65d8a2b1f2661@mail.gmail.com>
	<391a49da0807161431l585e6594r3be78475b671f271@mail.gmail.com>
	<c658be6b0807161440q75c92b10kf7a5584833a7a2ad@mail.gmail.com>
	<c658be6b0807161451p18e41aedj2afbe366dc210147@mail.gmail.com>
	<c658be6b0807161508w5276a1dbrdd7e9e386528eef5@mail.gmail.com>
	<c658be6b0807161513h123fa51cn38aa01ecd6a7975a@mail.gmail.com>
	<c658be6b0807161708h30d378eem327456cc259645e2@mail.gmail.com>
Message-ID: <391a49da0807181752g5967df8xee88e6022579e362@mail.gmail.com>

1. It doesn't work well when you try to mount it on a sub-directory
2. SCRIPT_NAME should be empty when it's mounted on root (even though
Camping can handle it).
3. REQUEST_URI contains query string too. What about
env['REQUEST_URI'].gsub(/\?.*/,'')?

It's not really a portable solution, so I don't think we should
publish this all over the internet, but it's good to hear that it's
working for you :-)

--

It seems that (almost) everything I said earlier was wrong: Now
PATH_INFO is suddenly / (I could have swear that it was gone!) And the
reason I got REDIRECT_SCRIPT_NAME was because I had a "SetEnv
SCRIPT_NAME /sub" in my .htaceess...

It also looks like it's impossible to auto magically detect what the
proper SCRIPT_NAME should be. I guess the "hack" should be put into
dispatch.cgi. What about this? http://pastie.org/236889

On Thu, Jul 17, 2008 at 2:08 AM, Eric Mill <kprojection at gmail.com> wrote:
> OK, I am good to go, working CGI and FastCGI .htaccess and dispatch.*
> files written.  I changed REDIRECT_URI to REQUEST_URI.
>
> For CGI:
> * dispatch.cgi: http://pastie.org/235313
> * .htaccess for CGI: http://pastie.org/235315
>
> For FastCGI, based on the above:
> * in dispatch.cgi, change Rack::Handler::CGI.run to be
> Rack::Handler::FastCGI.run
> * in .htaccess change dispatch.cgi to be dispatch.fcgi
>
> Awesome.  Thanks for everyone's help.  Especially Magnus and Jenna,
> you two rule.
>
> This seems like a good candidate for the github Camping wiki -- do
> people even know that thing exists, is it worth it?  Or should I just
> add it to the Camping wiki on why's site?
>
> -- Eric
>
> On Wed, Jul 16, 2008 at 6:13 PM, Eric Mill <kprojection at gmail.com> wrote:
>> The 500-handling I'm used to appears to be gone.  What's the best approach here?
>>
>> -- Eric
>>
>> On Wed, Jul 16, 2008 at 6:08 PM, Eric Mill <kprojection at gmail.com> wrote:
>>> I think I've got it working, with this as the 'fixer' call:
>>>
>>>  def call(env)
>>>    env['SCRIPT_NAME'] = '/'
>>>    env['PATH_INFO'] = env['REDIRECT_URL']
>>>    @app.call(env)
>>>  end
>>>
>>> I think you might have meant REDIRECT_URL and not REDIRECT_SCRIPT_NAME?
>>>
>>> Thank you Magnus!
>>>
>>> -- Eric
>>>
>>> On Wed, Jul 16, 2008 at 5:51 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>> Also worth noting is that PATH_INFO isn't emptied - it's set to "/" or
>>>> "/login", the correct request path.
>>>>
>>>> -- Eric
>>>>
>>>> On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>> Unfortunately this isn't working.  I'm checking my ENV and
>>>>> REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
>>>>> to try to figure out an alternative.
>>>>>
>>>>> Right now, requests to "/" go to a Camping error page which says
>>>>> "/index.html not found!"  and requests to "/login" (which should go to
>>>>> a different controller) says "/login.html not found!".  PATH_INFO has
>>>>> been set to "/login.html" in this case.
>>>>>
>>>>> I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
>>>>> this has the same effect as using the REDIRECT_SCRIPT_NAME approach.
>>>>>
>>>>> Continuing to investigate,
>>>>> Eric
>>>>>
>>>>> On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>>> Simply replace Testing with TestingFixed in dispatch.cgi:11 and
>>>>>> dispatch.fcgi:13 to see the diffenrence :-)
>>>>>>
>>>>>> On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>>> Magnus, this is terrific information, thank you for looking into this.
>>>>>>>
>>>>>>> I'm trying to follow your example - you use ApacheFixer to make a
>>>>>>> "TestingFixed" class, but never use that class anywhere else.  Do you
>>>>>>> mean for the lines in dispatch.* to use "TestingFixed" instead of
>>>>>>> "Testing"?
>>>>>>>
>>>>>>> I'm trying to use this to resolve my problems as we speak,
>>>>>>> Eric
>>>>>>>
>>>>>>> On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm <judofyr at gmail.com> wrote:
>>>>>>>> This "bug" is actually Apache's fault. The problem occurs when you use
>>>>>>>> mod_rewrite to hide that you're using dispatch.cgi. When you use
>>>>>>>> "RewriteRule ^(.*)$ dispatch.cgi" the following happens:
>>>>>>>>
>>>>>>>> * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script
>>>>>>>> which gets ran)
>>>>>>>> * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before
>>>>>>>> * PATH_INFO is emptied
>>>>>>>>
>>>>>>>> I've also tested this on 1.5 and it has the same problem. However, if
>>>>>>>> you use server/fastcgi.rb (not Rack as I've been testing with) you can
>>>>>>>> set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and
>>>>>>>> PATH_INFO using REQUEST_URI, which will (partly) solve the problem.
>>>>>>>>
>>>>>>>> Right now, we have no FORCE_ROOT in Rack, but here's a simple fix:
>>>>>>>>
>>>>>>>> * Change .htaccess to "RewriteRule ^(.*)$ dispatch.cgi/$1" (You might
>>>>>>>> need to drop to slash).
>>>>>>>> * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME
>>>>>>>> (http://pastie.org/235062)
>>>>>>>>
>>>>>>>> This isn't really our problem, but rather Apache (which should be able
>>>>>>>> to alias CGI-scripts with the correct headers). It probably won't
>>>>>>>> happen, so I guess we have to add some nasty hacks into Rack.
>>>>>>>>
>>>>>>>> I haven't tried this on any other servers (LightTPD/Nginx), but as
>>>>>>>> long as there is no URL-rewriting (I know LightTPD can do it with
>>>>>>>> FastCGI) it's probably no problem (maybe not even with, if it's smart
>>>>>>>> enough).
>>>>>>>>
>>>>>>>> Here is a simple app which shows @env (and works on both 1.5 and 2.0):
>>>>>>>> http://pastie.org/235078. It would be great if you could test it on
>>>>>>>> different setups and see which requires special treatment. Check out
>>>>>>>> the Rack-spec for how the variables should be set:
>>>>>>>> http://rack.rubyforge.org/doc/files/SPEC.html
>>>>>>>>
>>>>>>>> On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill <kprojection at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Bluebie -- I tried doing this with FastCGI with the same settings
>>>>>>>>> (changed .htaccess to point to dispatch.fcgi, changed dispatch file to
>>>>>>>>> use Rack::Handler::FastCGI.run, got the exact same results.  FastCGI
>>>>>>>>> will also suffer from these bugs.
>>>>>>>>>
>>>>>>>>> -- Eric
>>>>>>>>>
>>>>>>>>> On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna
>>>>>>>>> <blueberry at creativepony.com> wrote:
>>>>>>>>> > We are talking about cgi here, not fast cgi. Specifically CGI's interactions
>>>>>>>>> > with mod_rewrite in apache.
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Camping-list mailing list
>>>>>>>>> > Camping-list at rubyforge.org
>>>>>>>>> > http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> Camping-list mailing list
>>>>>>>>> Camping-list at rubyforge.org
>>>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Magnus Holm
>>>>>>>> _______________________________________________
>>>>>>>> Camping-list mailing list
>>>>>>>> Camping-list at rubyforge.org
>>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Camping-list mailing list
>>>>>>> Camping-list at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Magnus Holm
>>>>>> _______________________________________________
>>>>>> Camping-list mailing list
>>>>>> Camping-list at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From judofyr at gmail.com  Sat Jul 19 14:52:58 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 19 Jul 2008 20:52:58 +0200
Subject: Resolved: Apache + CGI/FastCGI + mod_rewrite
Message-ID: <391a49da0807191152j2f373731u26b617e8b2ac9784@mail.gmail.com>

This is the last time I try to fix something in the middle of the
night! Feel free to call me a Stupid Snake, 'cause this has been
messy. Anyway, I think I've finally solved this.

Here it is: http://pastie.org/237138 :-)

-- 
Magnus Holm

From judofyr at gmail.com  Sat Jul 19 16:43:42 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 19 Jul 2008 22:43:42 +0200
Subject: AR Sessions
In-Reply-To: <99d9e8df0807100801o64272090r41df7dbb2d9a3430@mail.gmail.com>
References: <99d9e8df0807100801o64272090r41df7dbb2d9a3430@mail.gmail.com>
Message-ID: <391a49da0807191343h69b037a9qf21a9b3d2fa02bb8@mail.gmail.com>

It looks like a bug in 2.1.0. For now, you should stick 'gem
"activerecord", "=2.0.2"' at the top of your app :-)

On Thu, Jul 10, 2008 at 5:01 PM, Joshua Miller <elefantstn at gmail.com> wrote:
> Hi all,
>
> I have a little camping micro-blog that's working well with the cookie
> session store, but falls over when I try to use the AR session store.
> The changes I made were:
>
> require 'camping/session' becomes require 'camping/ar/session'
>
> module Blog; include Camping::Session; end becomes module Blog;
> include Camping::ARSession; end
>
> and I did the create_schema in Blog.create.
>
> It set up the session table correctly, it adds a new row with a
> session id and sets a cookie on the browser correctly, but it never
> saves anything to the session state hash.  Do I need to do something
> differently to make @state save itself?  Using the cookie session
> store, changes are saved anytime I do something to @state, which is
> how I would expect it to work.
>
> I'm using the latest version from why's git repo with the default sqlite setup.
>
> Thanks!
> Josh
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From judofyr at gmail.com  Sat Jul 19 17:26:18 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 19 Jul 2008 23:26:18 +0200
Subject: Getting rid of the route maker
In-Reply-To: <20080707164636.GX7435@beekeeper.hobix.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
	<391a49da0807021752n4b2d12e6l9306c31b4372392@mail.gmail.com>
	<20080707164636.GX7435@beekeeper.hobix.com>
Message-ID: <391a49da0807191426m3315e736j9a367a9d1086d481@mail.gmail.com>

Sure, you're the boss. Camping is ready when you are ready!

Well, I don't have any new ideas. We just need to clean up the documentation!

On Mon, Jul 7, 2008 at 6:46 PM, _why <why at whytheluckystiff.net> wrote:
> On Thu, Jul 03, 2008 at 02:52:41AM +0200, Magnus Holm wrote:
>> Come on, you lazy interrogative! Are your shoes too heavy? :-(
>
> Bzzt!  (Drawing on backup camping power grids...)  Very sorry to be
> bad about this.  Yeah, lots of Shoes stuff going on this week as
> we're shooting for a July 31st release and there many bothersome bugs
> to smash.
>
> You've all done a lot of fanastic work and I say we keep working a
> bit longer.  I just merged zimbatm's week-old patches and I think it
> would be great if we could get more campers to mess with judofyr's
> gems, as I think camping 2.0 will inspire some breakages.
>
> Augusttime would be better for me, but let's talk about what you
> guys want to do.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From kprojection at gmail.com  Sat Jul 19 23:50:34 2008
From: kprojection at gmail.com (Eric Mill)
Date: Sat, 19 Jul 2008 23:50:34 -0400
Subject: Resolved: Apache + CGI/FastCGI + mod_rewrite
In-Reply-To: <391a49da0807191152j2f373731u26b617e8b2ac9784@mail.gmail.com>
References: <391a49da0807191152j2f373731u26b617e8b2ac9784@mail.gmail.com>
Message-ID: <c658be6b0807192050s56b3e3e0r488cdcae43af1848@mail.gmail.com>

Ah, hot damn, Magnus, you really took this problem to heart.  As the
creator of the "Camping on Dreamhost" wiki pages on the Camping and
Dreamhost wikis, I will be updating both with your work (and testing
it verbatim on Dreamhost).  You rule!

-- Eric

On Sat, Jul 19, 2008 at 2:52 PM, Magnus Holm <judofyr at gmail.com> wrote:
> This is the last time I try to fix something in the middle of the
> night! Feel free to call me a Stupid Snake, 'cause this has been
> messy. Anyway, I think I've finally solved this.
>
> Here it is: http://pastie.org/237138 :-)
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Sun Jul 20 14:16:11 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 20 Jul 2008 20:16:11 +0200
Subject: Preview: Camping Explained
Message-ID: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>

I'm going to start a new series on the cool stuff behind Camping, and would
like some feedback from the campers. Are everything understandable? Any
grammar/spelling errors? And please don't spread the link, I'll publish a
spreadable link later :-)

http://judofyr.net/drafts/camping-explained:the-beginning.html

-- 
Magnus Holm

From kprojection at gmail.com  Sun Jul 20 17:15:06 2008
From: kprojection at gmail.com (Eric Mill)
Date: Sun, 20 Jul 2008 17:15:06 -0400
Subject: Preview: Camping Explained
In-Reply-To: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>
References: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>
Message-ID: <c658be6b0807201415ndac3e87j22ffc287cefc5f7b@mail.gmail.com>

I like it.  The self-eval is stuff that was there when I jumped in at
1.5, so I knew how it worked, but it remains fascinating.  Suggested
future topics: How a class can inherit from something that takes
arguments (Index < R '/'), and what it takes to override #service for
middleware.  I don't understand the latter, and only half-understand
the former.

-- Eric

On Sun, Jul 20, 2008 at 2:16 PM, Magnus Holm <judofyr at gmail.com> wrote:
> I'm going to start a new series on the cool stuff behind Camping, and would
> like some feedback from the campers. Are everything understandable? Any
> grammar/spelling errors? And please don't spread the link, I'll publish a
> spreadable link later :-)
>
> http://judofyr.net/drafts/camping-explained:the-beginning.html
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From blueberry at creativepony.com  Sun Jul 20 18:13:52 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 21 Jul 2008 08:13:52 +1000
Subject: Preview: Camping Explained
In-Reply-To: <c658be6b0807201415ndac3e87j22ffc287cefc5f7b@mail.gmail.com>
References: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>
	<c658be6b0807201415ndac3e87j22ffc287cefc5f7b@mail.gmail.com>
Message-ID: <AB0C1B15-F53A-4100-B121-68560E8625CC@creativepony.com>

Neat! I like it ^_^

As for those queries, Eric, I believe the answer is that R is a method  
which returns a class.

Overriding services for middleware works because it's the job of  
'service' to call the get, post, type methods in the Controllers. By  
overriding it, we can use 'super' to call the original service method  
which runs the app controller, but we can add code above and below  
that call to 'super'. :)

From kprojection at gmail.com  Sun Jul 20 18:48:12 2008
From: kprojection at gmail.com (Eric Mill)
Date: Sun, 20 Jul 2008 18:48:12 -0400
Subject: Preview: Camping Explained
In-Reply-To: <AB0C1B15-F53A-4100-B121-68560E8625CC@creativepony.com>
References: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>
	<c658be6b0807201415ndac3e87j22ffc287cefc5f7b@mail.gmail.com>
	<AB0C1B15-F53A-4100-B121-68560E8625CC@creativepony.com>
Message-ID: <c658be6b0807201548q6617e118s75abeb77153baf07@mail.gmail.com>

I get that R is a method which returns the class; but it also uses a
lesser-known Ruby callback called Class#inherited
(http://www.ruby-doc.org/core/classes/Class.html#M000454) that blows
my mind and could use talking about.

The reason talking about #service would be cool is because it's not an
obvious function to decipher, yet is key to any developers getting
into Camping who might want to expand it like you and Magnus did.

-- Eric

On Sun, Jul 20, 2008 at 6:13 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> Neat! I like it ^_^
>
> As for those queries, Eric, I believe the answer is that R is a method which
> returns a class.
>
> Overriding services for middleware works because it's the job of 'service'
> to call the get, post, type methods in the Controllers. By overriding it, we
> can use 'super' to call the original service method which runs the app
> controller, but we can add code above and below that call to 'super'. :)
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From blueberry at creativepony.com  Sun Jul 20 20:46:29 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 21 Jul 2008 10:46:29 +1000
Subject: Backwards compatibility broken with URL()... for the better?
Message-ID: <5C7B5592-9BED-4F44-B88F-05AC97510F3E@creativepony.com>

In 1.5, to get a full url to ones camping app, you had to do:

this_url = 'http:' + URL('/some_action').to_s

Useful, for instance, in my openid consumer sample code, to give the  
openid doodad a return address

But in camping 1.9 off jud's gems, URL now returns actual url's with  
http: and everything at their fronts, which is rather snazzy... but  
breaking. Iunno, I kinda like this new fancy URL method that returns  
real URL's O_o

Jud's gem's session.rb still is including the IP address in the  
session hashing. I don't think we should recommend anyone use those  
gems till it's updated, I can only imagine how painfully frustrating  
it must be for user's in ISP's using AOL style load balanced  
transparent proxies who no matter what they do, can't get cookie  
session support to work in camping, with no errors or explanations.

From judofyr at gmail.com  Mon Jul 21 07:01:41 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 21 Jul 2008 13:01:41 +0200
Subject: Backwards compatibility broken with URL()... for the better?
In-Reply-To: <5C7B5592-9BED-4F44-B88F-05AC97510F3E@creativepony.com>
References: <5C7B5592-9BED-4F44-B88F-05AC97510F3E@creativepony.com>
Message-ID: <391a49da0807210401l29d66bafl6d3ef92774acf2b8@mail.gmail.com>

I have no problem with breaking backwards compatibility. After all, Camping
2.0 is a major upgrade.

About session.rb, even though it was I who wrote the code, _why merged it
(despite your warnings) and he's the to remove it :-)

On Mon, Jul 21, 2008 at 2:46 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> In 1.5, to get a full url to ones camping app, you had to do:
>
> this_url = 'http:' + URL('/some_action').to_s
>
> Useful, for instance, in my openid consumer sample code, to give the openid
> doodad a return address
>
> But in camping 1.9 off jud's gems, URL now returns actual url's with http:
> and everything at their fronts, which is rather snazzy... but breaking.
> Iunno, I kinda like this new fancy URL method that returns real URL's O_o
>
> Jud's gem's session.rb still is including the IP address in the session
> hashing. I don't think we should recommend anyone use those gems till it's
> updated, I can only imagine how painfully frustrating it must be for user's
> in ISP's using AOL style load balanced transparent proxies who no matter
> what they do, can't get cookie session support to work in camping, with no
> errors or explanations.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From judofyr at gmail.com  Mon Jul 21 07:10:51 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 21 Jul 2008 13:10:51 +0200
Subject: Preview: Camping Explained
In-Reply-To: <c658be6b0807201548q6617e118s75abeb77153baf07@mail.gmail.com>
References: <391a49da0807201116g421b7ee8je703bcbf79bf31e0@mail.gmail.com>
	<c658be6b0807201415ndac3e87j22ffc287cefc5f7b@mail.gmail.com>
	<AB0C1B15-F53A-4100-B121-68560E8625CC@creativepony.com>
	<c658be6b0807201548q6617e118s75abeb77153baf07@mail.gmail.com>
Message-ID: <391a49da0807210410j4ef53234p9499c284171fa34a@mail.gmail.com>

Both R and #service will be covered!

Here's the published url:
http://judofyr.net/posts/camping-explained:the-beginning.html :-)

On Mon, Jul 21, 2008 at 12:48 AM, Eric Mill <kprojection at gmail.com> wrote:
> I get that R is a method which returns the class; but it also uses a
> lesser-known Ruby callback called Class#inherited
> (http://www.ruby-doc.org/core/classes/Class.html#M000454) that blows
> my mind and could use talking about.
>
> The reason talking about #service would be cool is because it's not an
> obvious function to decipher, yet is key to any developers getting
> into Camping who might want to expand it like you and Magnus did.
>
> -- Eric
>
> On Sun, Jul 20, 2008 at 6:13 PM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
>> Neat! I like it ^_^
>>
>> As for those queries, Eric, I believe the answer is that R is a method which
>> returns a class.
>>
>> Overriding services for middleware works because it's the job of 'service'
>> to call the get, post, type methods in the Controllers. By overriding it, we
>> can use 'super' to call the original service method which runs the app
>> controller, but we can add code above and below that call to 'super'. :)
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From blueberry at creativepony.com  Mon Jul 21 22:33:04 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 22 Jul 2008 12:33:04 +1000
Subject: Backwards compatibility broken with URL()... for the better?
In-Reply-To: <391a49da0807210401l29d66bafl6d3ef92774acf2b8@mail.gmail.com>
References: <5C7B5592-9BED-4F44-B88F-05AC97510F3E@creativepony.com>
	<391a49da0807210401l29d66bafl6d3ef92774acf2b8@mail.gmail.com>
Message-ID: <50C839F2-8773-4C04-B542-D5BE930E754D@creativepony.com>

I thought your gems were based on your tree, not _why's? My mistake?

From blueberry at creativepony.com  Mon Jul 21 22:40:15 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 22 Jul 2008 12:40:15 +1000
Subject: File uploads
Message-ID: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>

NoMethodError undefined method `tempfile' for #

That sure is odd... I guess in Camping 2.0, uploads are not a  
Camping::H. Can we please change Camping::H to output ::H's instead of  
the original value when the original value is_a?(::H)

That be good. Recursive yumminess. Doesn't solve hashes in arrays, but  
is nice for this and some other things like playing with JSON. :)

Looks like to do that, we'd need to override Hash#fetch, and maybe  
Hash#[] and stuff... complex, maybe beyond camping scope. Still, I  
really think for consistency file upload hashes in the @input should  
be ::H's. Maybe not put the functionality in ::H, maybe some  
processing specific to @input.

Coming right down to it, I'm thinking about putting the functionality  
in the actual Hash class.... why don't we do that normally? does it  
cause problems with some libraries?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080722/290abc4d/attachment.html>

From judofyr at gmail.com  Tue Jul 22 06:04:16 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 22 Jul 2008 12:04:16 +0200
Subject: Backwards compatibility broken with URL()... for the better?
In-Reply-To: <50C839F2-8773-4C04-B542-D5BE930E754D@creativepony.com>
References: <5C7B5592-9BED-4F44-B88F-05AC97510F3E@creativepony.com>
	<391a49da0807210401l29d66bafl6d3ef92774acf2b8@mail.gmail.com>
	<50C839F2-8773-4C04-B542-D5BE930E754D@creativepony.com>
Message-ID: <391a49da0807220304g75313a32u9344d969995f8445@mail.gmail.com>

Yes and no. The gems are based on my tree, but I'll always try to keep my
tree equal to _why's. If there's some commits I'm not sure if he will merge, I
put them in a branch (so I don't mess up the master).

On Tue, Jul 22, 2008 at 4:33 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> I thought your gems were based on your tree, not _why's? My mistake?
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From zimbatm at oree.ch  Tue Jul 22 06:39:57 2008
From: zimbatm at oree.ch (zimbatm)
Date: Tue, 22 Jul 2008 12:39:57 +0200
Subject: File uploads
In-Reply-To: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
Message-ID: <e3caf1460807220339m666db866s9f73cfe9596119c2@mail.gmail.com>

class H < Hash
    # Gets or sets keys in the hash.
    #
    #   @cookies.my_favorite = :macadamian
    #   @cookies.my_favorite
    #   => :macadamian
    #
    def method_missing(m,*a)
        x=(m.to_s=~/=$/?self[$`]=a[0]:a==[]?self[m.to_s]:super)
        x.kind_of?(Hash) ? H[x] : x
    end
    undef id, type
  end

2008/7/22 Bluebie, Jenna <blueberry at creativepony.com>:
> NoMethodError undefined method `tempfile' for #
> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
> Can we please change Camping::H to output ::H's instead of the original
> value when the original value is_a?(::H)
> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
> nice for this and some other things like playing with JSON. :)
> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
> and stuff... complex, maybe beyond camping scope. Still, I really think
> for consistency file upload hashes in the @input should be ::H's. Maybe not
> put the functionality in ::H, maybe some processing specific to @input.
> Coming right down to it, I'm thinking about putting the functionality in the
> actual Hash class.... why don't we do that normally? does it cause problems
> with some libraries?
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Tue Jul 22 18:40:42 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 23 Jul 2008 00:40:42 +0200
Subject: File uploads
In-Reply-To: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
Message-ID: <391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>

I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really
nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash.
It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3
if you drop
the latest patch.

I don't know if it's worth another dependency; maybe zimbatm's patch is
better.

On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> NoMethodError undefined method `tempfile' for #
> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
> Can we please change Camping::H to output ::H's instead of the original
> value when the original value is_a?(::H)
> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
> nice for this and some other things like playing with JSON. :)
> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
> and stuff... complex, maybe beyond camping scope. Still, I really think
> for consistency file upload hashes in the @input should be ::H's. Maybe not
> put the functionality in ::H, maybe some processing specific to @input.
> Coming right down to it, I'm thinking about putting the functionality in the
> actual Hash class.... why don't we do that normally? does it cause problems
> with some libraries?
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From zimbatm at oree.ch  Wed Jul 23 04:10:23 2008
From: zimbatm at oree.ch (zimbatm)
Date: Wed, 23 Jul 2008 10:10:23 +0200
Subject: File uploads
In-Reply-To: <391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
	<391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>
Message-ID: <e3caf1460807230110r9284276j913b39a476dc2ec0@mail.gmail.com>

Yum. Did you try just setting YourApp::H = Mash ? If it works like
this out of the box
then we can keep the simpler solution and provide a recipe to work with mash ?

2008/7/23 Magnus Holm <judofyr at gmail.com>:
> I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really
> nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash.
> It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3
> if you drop
> the latest patch.
>
> I don't know if it's worth another dependency; maybe zimbatm's patch is
> better.
>
> On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
>> NoMethodError undefined method `tempfile' for #
>> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
>> Can we please change Camping::H to output ::H's instead of the original
>> value when the original value is_a?(::H)
>> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
>> nice for this and some other things like playing with JSON. :)
>> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
>> and stuff... complex, maybe beyond camping scope. Still, I really think
>> for consistency file upload hashes in the @input should be ::H's. Maybe not
>> put the functionality in ::H, maybe some processing specific to @input.
>> Coming right down to it, I'm thinking about putting the functionality in the
>> actual Hash class.... why don't we do that normally? does it cause problems
>> with some libraries?
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Wed Jul 23 04:51:22 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 23 Jul 2008 10:51:22 +0200
Subject: File uploads
In-Reply-To: <e3caf1460807230110r9284276j913b39a476dc2ec0@mail.gmail.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
	<391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>
	<e3caf1460807230110r9284276j913b39a476dc2ec0@mail.gmail.com>
Message-ID: <391a49da0807230151t3c117a8cq6477b547663d077c@mail.gmail.com>

Mash[] doesn't work exactly as wanted (if you give it symbols):

Mash[:test => 1]             #=> <Mash test=nil>
Mash[:test => 1, :cool => 2] #=> Raises error

So we have to alias self[] to self.new...

On Wed, Jul 23, 2008 at 10:10 AM, zimbatm <zimbatm at oree.ch> wrote:
> Yum. Did you try just setting YourApp::H = Mash ? If it works like
> this out of the box
> then we can keep the simpler solution and provide a recipe to work with mash ?
>
> 2008/7/23 Magnus Holm <judofyr at gmail.com>:
>> I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really
>> nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash.
>> It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3
>> if you drop
>> the latest patch.
>>
>> I don't know if it's worth another dependency; maybe zimbatm's patch is
>> better.
>>
>> On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna
>> <blueberry at creativepony.com> wrote:
>>> NoMethodError undefined method `tempfile' for #
>>> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
>>> Can we please change Camping::H to output ::H's instead of the original
>>> value when the original value is_a?(::H)
>>> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
>>> nice for this and some other things like playing with JSON. :)
>>> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
>>> and stuff... complex, maybe beyond camping scope. Still, I really think
>>> for consistency file upload hashes in the @input should be ::H's. Maybe not
>>> put the functionality in ::H, maybe some processing specific to @input.
>>> Coming right down to it, I'm thinking about putting the functionality in the
>>> actual Hash class.... why don't we do that normally? does it cause problems
>>> with some libraries?
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>>
>> --
>> Magnus Holm
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From zimbatm at oree.ch  Wed Jul 23 10:49:27 2008
From: zimbatm at oree.ch (zimbatm)
Date: Wed, 23 Jul 2008 16:49:27 +0200
Subject: File uploads
In-Reply-To: <391a49da0807230151t3c117a8cq6477b547663d077c@mail.gmail.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
	<391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>
	<e3caf1460807230110r9284276j913b39a476dc2ec0@mail.gmail.com>
	<391a49da0807230151t3c117a8cq6477b547663d077c@mail.gmail.com>
Message-ID: <e3caf1460807230749i41da26eaxbcbc1509d5ae6e93@mail.gmail.com>

This is curious... why would they change that behavior ?

2008/7/23 Magnus Holm <judofyr at gmail.com>:
> Mash[] doesn't work exactly as wanted (if you give it symbols):
>
> Mash[:test => 1]             #=> <Mash test=nil>
> Mash[:test => 1, :cool => 2] #=> Raises error
>
> So we have to alias self[] to self.new...
>
> On Wed, Jul 23, 2008 at 10:10 AM, zimbatm <zimbatm at oree.ch> wrote:
>> Yum. Did you try just setting YourApp::H = Mash ? If it works like
>> this out of the box
>> then we can keep the simpler solution and provide a recipe to work with mash ?
>>
>> 2008/7/23 Magnus Holm <judofyr at gmail.com>:
>>> I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really
>>> nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash.
>>> It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3
>>> if you drop
>>> the latest patch.
>>>
>>> I don't know if it's worth another dependency; maybe zimbatm's patch is
>>> better.
>>>
>>> On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna
>>> <blueberry at creativepony.com> wrote:
>>>> NoMethodError undefined method `tempfile' for #
>>>> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
>>>> Can we please change Camping::H to output ::H's instead of the original
>>>> value when the original value is_a?(::H)
>>>> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
>>>> nice for this and some other things like playing with JSON. :)
>>>> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
>>>> and stuff... complex, maybe beyond camping scope. Still, I really think
>>>> for consistency file upload hashes in the @input should be ::H's. Maybe not
>>>> put the functionality in ::H, maybe some processing specific to @input.
>>>> Coming right down to it, I'm thinking about putting the functionality in the
>>>> actual Hash class.... why don't we do that normally? does it cause problems
>>>> with some libraries?
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>
>>>
>>>
>>> --
>>> Magnus Holm
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Sat Jul 26 15:36:27 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 26 Jul 2008 21:36:27 +0200
Subject: File uploads
In-Reply-To: <e3caf1460807230749i41da26eaxbcbc1509d5ae6e93@mail.gmail.com>
References: <7B4B09BB-BCB3-4A64-93FB-0231C3EE18B3@creativepony.com>
	<391a49da0807221540k27cfdf57xf96abaff9f79fbfc@mail.gmail.com>
	<e3caf1460807230110r9284276j913b39a476dc2ec0@mail.gmail.com>
	<391a49da0807230151t3c117a8cq6477b547663d077c@mail.gmail.com>
	<e3caf1460807230749i41da26eaxbcbc1509d5ae6e93@mail.gmail.com>
Message-ID: <391a49da0807261236u7fcfd1eeuea0762345e88c2c0@mail.gmail.com>

They havent't changed the method. They probabely should.

When you run Mash.new it transforms all keys to strings (and turns
Hash'es to Mash'es), Mash[] doesn't do anything like that. And it
isn't Mash[:test => 1, :cool => 2] which raises errors, it's when you
call #inspect on it (it tries to sort all the keys).

On Wed, Jul 23, 2008 at 4:49 PM, zimbatm <zimbatm at oree.ch> wrote:
> This is curious... why would they change that behavior ?
>
> 2008/7/23 Magnus Holm <judofyr at gmail.com>:
>> Mash[] doesn't work exactly as wanted (if you give it symbols):
>>
>> Mash[:test => 1]             #=> <Mash test=nil>
>> Mash[:test => 1, :cool => 2] #=> Raises error
>>
>> So we have to alias self[] to self.new...
>>
>> On Wed, Jul 23, 2008 at 10:10 AM, zimbatm <zimbatm at oree.ch> wrote:
>>> Yum. Did you try just setting YourApp::H = Mash ? If it works like
>>> this out of the box
>>> then we can keep the simpler solution and provide a recipe to work with mash ?
>>>
>>> 2008/7/23 Magnus Holm <judofyr at gmail.com>:
>>>> I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really
>>>> nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash.
>>>> It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3
>>>> if you drop
>>>> the latest patch.
>>>>
>>>> I don't know if it's worth another dependency; maybe zimbatm's patch is
>>>> better.
>>>>
>>>> On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna
>>>> <blueberry at creativepony.com> wrote:
>>>>> NoMethodError undefined method `tempfile' for #
>>>>> That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H.
>>>>> Can we please change Camping::H to output ::H's instead of the original
>>>>> value when the original value is_a?(::H)
>>>>> That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is
>>>>> nice for this and some other things like playing with JSON. :)
>>>>> Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[]
>>>>> and stuff... complex, maybe beyond camping scope. Still, I really think
>>>>> for consistency file upload hashes in the @input should be ::H's. Maybe not
>>>>> put the functionality in ::H, maybe some processing specific to @input.
>>>>> Coming right down to it, I'm thinking about putting the functionality in the
>>>>> actual Hash class.... why don't we do that normally? does it cause problems
>>>>> with some libraries?
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Magnus Holm
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>>
>> --
>> Magnus Holm
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From fophillips at fophillips.org  Mon Jul 28 18:05:11 2008
From: fophillips at fophillips.org (Fred Phillips)
Date: Mon, 28 Jul 2008 23:05:11 +0100
Subject: @state not being saved
Message-ID: <20080728220511.GB11883@tarkin.tarkin.lan>

I have a sqlite3 database with the sessions table and schema set up
correctly. Sessions are created fine and put in the table, the cookie
is set with the correct hash and the hash is found again but when
using @state the values aren?t updated in the table.

I know that Session::service is called and the contents of the record
are put into session like so:
#<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {}>

I do @state.user = 5, then it then gets as far as making session look
like this:
#<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {"TLCMS"=>{"user"=>5}}>

But then session.save doesn?t write to the table, and doesn?t throw an
error (session.save! doesn?t either). Can anyone see what is going
wrong?

FWIW I?m using FastCGI

--
Fred O. Phillips
http://fophillips.org
BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080728/569e968f/attachment.bin>

From kprojection at gmail.com  Tue Jul 29 00:15:52 2008
From: kprojection at gmail.com (Eric Mill)
Date: Tue, 29 Jul 2008 00:15:52 -0400
Subject: @state not being saved
In-Reply-To: <20080728220511.GB11883@tarkin.tarkin.lan>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
Message-ID: <c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>

Is this with Camping 1.5 or Camping 2.0?

-- Eric

On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
<fophillips at fophillips.org> wrote:
> I have a sqlite3 database with the sessions table and schema set up
> correctly. Sessions are created fine and put in the table, the cookie
> is set with the correct hash and the hash is found again but when
> using @state the values aren't updated in the table.
>
> I know that Session::service is called and the contents of the record
> are put into session like so:
> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {}>
>
> I do @state.user = 5, then it then gets as far as making session look
> like this:
> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {"TLCMS"=>{"user"=>5}}>
>
> But then session.save doesn't write to the table, and doesn't throw an
> error (session.save! doesn't either). Can anyone see what is going
> wrong?
>
> FWIW I'm using FastCGI
>
> --
> Fred O. Phillips
> http://fophillips.org
> BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From alpha.chen at gmail.com  Tue Jul 29 01:10:44 2008
From: alpha.chen at gmail.com (Alpha Chen)
Date: Mon, 28 Jul 2008 22:10:44 -0700
Subject: @state not being saved
In-Reply-To: <c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
Message-ID: <e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>

This happened to me... I saw an email on this list earlier about AR
2.1.0 having problems, and reverting back to 2.0.2 got session support
working again.

On the command line:
$ gem install --version '=2.0.2' activerecord

In Camping:
gem 'activerecord', '=2.0.2'

Alpha

On Mon, Jul 28, 2008 at 9:15 PM, Eric Mill <kprojection at gmail.com> wrote:
> Is this with Camping 1.5 or Camping 2.0?
>
> -- Eric
>
> On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
> <fophillips at fophillips.org> wrote:
>> I have a sqlite3 database with the sessions table and schema set up
>> correctly. Sessions are created fine and put in the table, the cookie
>> is set with the correct hash and the hash is found again but when
>> using @state the values aren't updated in the table.
>>
>> I know that Session::service is called and the contents of the record
>> are put into session like so:
>> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {}>
>>
>> I do @state.user = 5, then it then gets as far as making session look
>> like this:
>> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {"TLCMS"=>{"user"=>5}}>
>>
>> But then session.save doesn't write to the table, and doesn't throw an
>> error (session.save! doesn't either). Can anyone see what is going
>> wrong?
>>
>> FWIW I'm using FastCGI
>>
>> --
>> Fred O. Phillips
>> http://fophillips.org
>> BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From kprojection at gmail.com  Tue Jul 29 09:36:05 2008
From: kprojection at gmail.com (Eric Mill)
Date: Tue, 29 Jul 2008 09:36:05 -0400
Subject: @state not being saved
In-Reply-To: <e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
Message-ID: <c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>

Is it that AR 2.1 only has problems in conjunction with Camping?  Or
is table-based session support totally broken in Rails 2.1 right now?

-- Eric

On Tue, Jul 29, 2008 at 1:10 AM, Alpha Chen <alpha.chen at gmail.com> wrote:
> This happened to me... I saw an email on this list earlier about AR
> 2.1.0 having problems, and reverting back to 2.0.2 got session support
> working again.
>
> On the command line:
> $ gem install --version '=2.0.2' activerecord
>
> In Camping:
> gem 'activerecord', '=2.0.2'
>
> Alpha
>
> On Mon, Jul 28, 2008 at 9:15 PM, Eric Mill <kprojection at gmail.com> wrote:
>> Is this with Camping 1.5 or Camping 2.0?
>>
>> -- Eric
>>
>> On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
>> <fophillips at fophillips.org> wrote:
>>> I have a sqlite3 database with the sessions table and schema set up
>>> correctly. Sessions are created fine and put in the table, the cookie
>>> is set with the correct hash and the hash is found again but when
>>> using @state the values aren't updated in the table.
>>>
>>> I know that Session::service is called and the contents of the record
>>> are put into session like so:
>>> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {}>
>>>
>>> I do @state.user = 5, then it then gets as far as making session look
>>> like this:
>>> #<Camping::Models::Session id: 1, hashid: "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43", ivars: {"TLCMS"=>{"user"=>5}}>
>>>
>>> But then session.save doesn't write to the table, and doesn't throw an
>>> error (session.save! doesn't either). Can anyone see what is going
>>> wrong?
>>>
>>> FWIW I'm using FastCGI
>>>
>>> --
>>> Fred O. Phillips
>>> http://fophillips.org
>>> BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From fophillips at fophillips.org  Tue Jul 29 10:04:51 2008
From: fophillips at fophillips.org (Fred Phillips)
Date: Tue, 29 Jul 2008 15:04:51 +0100
Subject: @state not being saved
In-Reply-To: <e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
Message-ID: <20080729140451.GA4270@tarkin.tarkin.lan>

On Mon Jul 28 22:10:44 2008, Alpha Chen wrote:
> This happened to me... I saw an email on this list earlier about AR
> 2.1.0 having problems, and reverting back to 2.0.2 got session support
> working again.
> 
> On the command line:
> $ gem install --version '=2.0.2' activerecord
> 
> In Camping:
> gem 'activerecord', '=2.0.2'
> 
> Alpha
> 

Thanks, worked perfectly.

-- 
Fred O. Phillips
http://fophillips.org
BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080729/ffc4fd38/attachment.bin>

From judofyr at gmail.com  Tue Jul 29 10:11:11 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 29 Jul 2008 16:11:11 +0200
Subject: @state not being saved
In-Reply-To: <c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
	<c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>
Message-ID: <391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>

For some reason, AR 1.2 can't save serialized data. At least in the
tests I have done with Camping's Session model.

For now we have to stick with 2.0.2, but I know the problem has been reported.

2008/7/29, Eric Mill <kprojection at gmail.com>:
> Is it that AR 2.1 only has problems in conjunction with Camping?  Or
> is table-based session support totally broken in Rails 2.1 right now?
>
> -- Eric
>
> On Tue, Jul 29, 2008 at 1:10 AM, Alpha Chen <alpha.chen at gmail.com> wrote:
>> This happened to me... I saw an email on this list earlier about AR
>> 2.1.0 having problems, and reverting back to 2.0.2 got session support
>> working again.
>>
>> On the command line:
>> $ gem install --version '=2.0.2' activerecord
>>
>> In Camping:
>> gem 'activerecord', '=2.0.2'
>>
>> Alpha
>>
>> On Mon, Jul 28, 2008 at 9:15 PM, Eric Mill <kprojection at gmail.com> wrote:
>>> Is this with Camping 1.5 or Camping 2.0?
>>>
>>> -- Eric
>>>
>>> On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
>>> <fophillips at fophillips.org> wrote:
>>>> I have a sqlite3 database with the sessions table and schema set up
>>>> correctly. Sessions are created fine and put in the table, the cookie
>>>> is set with the correct hash and the hash is found again but when
>>>> using @state the values aren't updated in the table.
>>>>
>>>> I know that Session::service is called and the contents of the record
>>>> are put into session like so:
>>>> #<Camping::Models::Session id: 1, hashid:
>>>> "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43",
>>>> ivars: {}>
>>>>
>>>> I do @state.user = 5, then it then gets as far as making session look
>>>> like this:
>>>> #<Camping::Models::Session id: 1, hashid:
>>>> "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24 17:11:43",
>>>> ivars: {"TLCMS"=>{"user"=>5}}>
>>>>
>>>> But then session.save doesn't write to the table, and doesn't throw an
>>>> error (session.save! doesn't either). Can anyone see what is going
>>>> wrong?
>>>>
>>>> FWIW I'm using FastCGI
>>>>
>>>> --
>>>> Fred O. Phillips
>>>> http://fophillips.org
>>>> BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>


-- 
Magnus Holm

From blueberry at creativepony.com  Tue Jul 29 11:13:36 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Wed, 30 Jul 2008 01:13:36 +1000
Subject: @state not being saved
In-Reply-To: <391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
	<c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>
	<391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>
Message-ID: <C2AFBAB9-2F80-4CB3-ACD9-8C5387F7811A@creativepony.com>

Also worth noting that camping includes it's own session support.  
We're not using bits from rails for sessions except for ActiveRecord  
itself, and then only if you're using active record sessions. You  
might like to try the cookie sessions included in current Camping 2.0  
builds (Magnus has more info on where you can grab those gems) which  
doesn't depend on ActiveRecord, if your session data can fit in under  
a couple of KB's. There's also an older though fully functional  
implementation of cookie sessions on the wiki for 1.5 by yours truly. :)

essentially it works by storing the @state hash in a cookie, and  
digitally signing the data with an SHA hash of some sort, so while the  
user can see what's in their session if they're determined enough,  
they cannot tamper with it without knowing rather secret details about  
your server environment. You can also provide a custom key in your  
code for it to use for security bonus points. Without the key, so long  
as SHA isn't ever broken, they won't be able to tamper with the data  
without the server realizing and invalidating the session, starting  
them afresh. :)

I really hope the ActiveRecord crew sort this out before we get too  
close to releasing 2.0 officially! :)

From julian.tarkhanov at gmail.com  Wed Jul 30 08:12:18 2008
From: julian.tarkhanov at gmail.com (Julik Tarkhanov)
Date: Wed, 30 Jul 2008 14:12:18 +0200
Subject: @state not being saved
In-Reply-To: <C2AFBAB9-2F80-4CB3-ACD9-8C5387F7811A@creativepony.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
	<c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>
	<391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>
	<C2AFBAB9-2F80-4CB3-ACD9-8C5387F7811A@creativepony.com>
Message-ID: <7976366B-31EC-424B-83F8-97E9F16767CE@gmail.com>

I've pointed to the fact that its not a problem of activerecord but  
the stubbornness of the camping session module (insisting on natural  
primary key) that keeps it from working

-- 
Julian "Julik" Tarkhanov

On 29-jul-2008, at 17:13, "Bluebie, Jenna"  
<blueberry at creativepony.com> wrote:

> Also worth noting that camping includes it's own session support.  
> We're not using bits from rails for sessions except for ActiveRecord  
> itself, and then only if you're using active record sessions. You  
> might like to try the cookie sessions included in current Camping  
> 2.0 builds (Magnus has more info on where you can grab those gems)  
> which doesn't depend on ActiveRecord, if your session data can fit  
> in under a couple of KB's. There's also an older though fully  
> functional implementation of cookie sessions on the wiki for 1.5 by  
> yours truly. :)
>
> essentially it works by storing the @state hash in a cookie, and  
> digitally signing the data with an SHA hash of some sort, so while  
> the user can see what's in their session if they're determined  
> enough, they cannot tamper with it without knowing rather secret  
> details about your server environment. You can also provide a custom  
> key in your code for it to use for security bonus points. Without  
> the key, so long as SHA isn't ever broken, they won't be able to  
> tamper with the data without the server realizing and invalidating  
> the session, starting them afresh. :)
>
> I really hope the ActiveRecord crew sort this out before we get too  
> close to releasing 2.0 officially! :)
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

From julian.tarkhanov at gmail.com  Wed Jul 30 08:13:50 2008
From: julian.tarkhanov at gmail.com (Julik Tarkhanov)
Date: Wed, 30 Jul 2008 14:13:50 +0200
Subject: @state not being saved
In-Reply-To: <391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>
References: <20080728220511.GB11883@tarkin.tarkin.lan>
	<c658be6b0807282115m1f296a4aif613095ceeb3c6c5@mail.gmail.com>
	<e54c16cf0807282210t819056ds71bfb73a92bf4fd3@mail.gmail.com>
	<c658be6b0807290636y508ebe71u800ab877888dac28@mail.gmail.com>
	<391a49da0807290711k75096ad0x1a99771bfb04af1e@mail.gmail.com>
Message-ID: <41BE6AB5-8DE4-4E3F-8763-83E381A97ABA@gmail.com>

ActiveRecord::Base.partial_updates = false
and you should be good to go

--  
Julian "Julik" Tarkhanov

On 29-jul-2008, at 16:11, "Magnus Holm" <judofyr at gmail.com> wrote:

> For some reason, AR 1.2 can't save serialized data. At least in the
> tests I have done with Camping's Session model.
>
> For now we have to stick with 2.0.2, but I know the problem has been  
> reported.
>
> 2008/7/29, Eric Mill <kprojection at gmail.com>:
>> Is it that AR 2.1 only has problems in conjunction with Camping?  Or
>> is table-based session support totally broken in Rails 2.1 right now?
>>
>> -- Eric
>>
>> On Tue, Jul 29, 2008 at 1:10 AM, Alpha Chen <alpha.chen at gmail.com>  
>> wrote:
>>> This happened to me... I saw an email on this list earlier about AR
>>> 2.1.0 having problems, and reverting back to 2.0.2 got session  
>>> support
>>> working again.
>>>
>>> On the command line:
>>> $ gem install --version '=2.0.2' activerecord
>>>
>>> In Camping:
>>> gem 'activerecord', '=2.0.2'
>>>
>>> Alpha
>>>
>>> On Mon, Jul 28, 2008 at 9:15 PM, Eric Mill <kprojection at gmail.com>  
>>> wrote:
>>>> Is this with Camping 1.5 or Camping 2.0?
>>>>
>>>> -- Eric
>>>>
>>>> On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
>>>> <fophillips at fophillips.org> wrote:
>>>>> I have a sqlite3 database with the sessions table and schema set  
>>>>> up
>>>>> correctly. Sessions are created fine and put in the table, the  
>>>>> cookie
>>>>> is set with the correct hash and the hash is found again but when
>>>>> using @state the values aren't updated in the table.
>>>>>
>>>>> I know that Session::service is called and the contents of the  
>>>>> record
>>>>> are put into session like so:
>>>>> #<Camping::Models::Session id: 1, hashid:
>>>>> "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24  
>>>>> 17:11:43",
>>>>> ivars: {}>
>>>>>
>>>>> I do @state.user = 5, then it then gets as far as making session  
>>>>> look
>>>>> like this:
>>>>> #<Camping::Models::Session id: 1, hashid:
>>>>> "iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4", created_at: "2008-07-24  
>>>>> 17:11:43",
>>>>> ivars: {"TLCMS"=>{"user"=>5}}>
>>>>>
>>>>> But then session.save doesn't write to the table, and doesn't  
>>>>> throw an
>>>>> error (session.save! doesn't either). Can anyone see what is going
>>>>> wrong?
>>>>>
>>>>> FWIW I'm using FastCGI
>>>>>
>>>>> --
>>>>> Fred O. Phillips
>>>>> http://fophillips.org
>>>>> BBC7 7572 755F 83E0 3209  504A E4F7 874F 1545 9D41
>>>>>
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> -- 
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list