Re: Semantic problems with mod_rewrite and [F]CGI scripts.

On Fri, Sep 17, 2004 at 11:07:45AM -0600, Aredridel wrote:
> I've been working with the Ruby on Rails crowd, trying to make Lighttpd
> work with the Rails development environment/framework.
> 
> At its core, Rails is just a web app framework, but it does depend on a
> URL-rewriter, specifically mapping URLS in the form
> of /base/CCC/AAA/III?qqq to /dispatch.[f]cgi?
> controller=CCC&action=AAA&id=III&qqq
> 
> It also needs to be able to construct self-referencing URLs, and that's
> where trouble strikes. The CGI and FastCGI specs are notably silent on
> issues like this, mostly because URL-rewriting is completely black
> magic.
> 
> In the case of a rewrite like that, Lighttpd sends a REQUEST_URI
> of /dispatch.fcgi?controller=CCC&action=AAA&id=III. Rails has no way to
> know what URL the user is seeing, and can't construct an appropriate URL
> for other actions.
> 
> Apache (and I'm hardly arguing that what Apache does is right) puts the
> original URI in REQUEST_URI, and the docs for other apache modules hint
> that it should put the rewritten in REDIRECT_URI (or vice versa). In
> practice, it puts the original in the REDIRECT_URI, too.
> 
> I'd love ideas on what the Right Thing might look like, and secondarily,
> clean ways to implement them in lighttpd. I have an experimental patch
> (http://codepaste.net/view/paste/147) that makes Rails go, but it's not
> semantically clean at all.

Good question:

REQUEST_URI should stay at the original value as sent in by the user.
The idea was to have 3 structures:

connection.request (parsed HTTP-request)
connection.internal_request (a copy of request + rewrites ...)
connection.response (the prepared HTTP-response)

internal_request will be the structure that you are actually working on.

I'll add that in a minute.
 
> Have a good day.
> 
> Ari
 
    Jan
  
-- 
Jan Kneschke                                     http://jan.kneschke.de/
Perhaps you want to say 'thank you, jan':    http://jk.123.org/wishlist/