From lists at ruby-forum.com Thu Mar 5 12:33:46 2009 From: lists at ruby-forum.com (John Nestoriak) Date: Thu, 5 Mar 2009 18:33:46 +0100 Subject: [Mongrel] Can you make Mongrel listen on a specific IP Message-ID: <4a894c56f0a9436a1d89b809d4fb5f51@ruby-forum.com> Shared hosting environment where each domain has it's own IP. Some use mongrel server to run their rails apps. Mongrels of course listen on their own port. But ... If client1.com has a mongrel listening on 12001 you can go to client2.com:12001 and see client1's site. Not a huge issue but it's kinda funky. I don't see an ip in mongrel's startup options but perhaps I'm missing a way to get the mongrel server to only listen on a specific ip address. Or has anyone else run into this and come up with a good solution? -- Posted via http://www.ruby-forum.com/. From nicholson.roy at gmail.com Thu Mar 5 14:12:05 2009 From: nicholson.roy at gmail.com (Roy Nicholson) Date: Thu, 05 Mar 2009 14:12:05 -0500 Subject: [Mongrel] Can you make Mongrel listen on a specific IP In-Reply-To: <4a894c56f0a9436a1d89b809d4fb5f51@ruby-forum.com> References: <4a894c56f0a9436a1d89b809d4fb5f51@ruby-forum.com> Message-ID: <49B02405.6010809@gmail.com> John Nestoriak wrote: > Shared hosting environment where each domain has it's own IP. Some use > mongrel server to run their rails apps. Mongrels of course listen on > their own port. But ... > > If client1.com has a mongrel listening on 12001 you can go to > client2.com:12001 and see client1's site. > > Not a huge issue but it's kinda funky. > > I don't see an ip in mongrel's startup options but perhaps I'm missing a > way to get the mongrel server to only listen on a specific ip address. > > Or has anyone else run into this and come up with a good solution? > The --address /-a option sounds like what you're looking for. mongrel_rails start --help ... -a, --address ADDR Address to bind to ... usage example: mongrel_rails start --address 127.0.0.1 -p 12001 From lists at ruby-forum.com Sat Mar 7 21:39:38 2009 From: lists at ruby-forum.com (Gokul Cv) Date: Sun, 8 Mar 2009 03:39:38 +0100 Subject: [Mongrel] error : Redmine Message-ID: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> Hello, Iam getting the following error whem adding new task in redmine -- Internal error An error occurred on the page you were trying to access. If you continue to experience problems please contact your redMine administrator for assistance. Please advise. Thanks in advance. Regards, Gokul -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Sun Mar 8 11:13:22 2009 From: wyhaines at gmail.com (wyhaines at gmail.com) Date: Sun, 8 Mar 2009 15:13:22 +0000 Subject: [Mongrel] error : Redmine Message-ID: <1636711565-1236525185-cardhu_decombobulator_blackberry.rim.net-383618363-@bxe1024.bisx.prod.on.blackberry> That is an error from redmine and is not from mongrel. You should double check your redmine installation and if you are still having problems then seek help in a redmine specific forum. Kirk Haines ------Original Message------ From: Gokul Cv Sender: mongrel-users-bounces at rubyforge.org To: mongrel-users at rubyforge.org ReplyTo: mongrel-users at rubyforge.org Subject: [Mongrel] error : Redmine Sent: Mar 7, 2009 19:39 Hello, Iam getting the following error whem adding new task in redmine -- Internal error An error occurred on the page you were trying to access. If you continue to experience problems please contact your redMine administrator for assistance. Please advise. Thanks in advance. Regards, Gokul -- Posted via http://www.ruby-forum.com/. _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users Sent from my Verizon Wireless BlackBerry From lists at ruby-forum.com Tue Mar 10 20:42:51 2009 From: lists at ruby-forum.com (Gokul Cv) Date: Wed, 11 Mar 2009 01:42:51 +0100 Subject: [Mongrel] error : Redmine In-Reply-To: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> References: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> Message-ID: <2555fb5895b0e2272a9e9ef45cfa32dd@ruby-forum.com> Hello, I also find that the stuff to do plugin is broken. It seems it has not been installed correctly. Will this be contributing to the error? . Accessing it displays the same error as mentioned before-- Internal error An error occurred on the page you were trying to access. If you continue to experience problems please contact your redMine administrator for assistance. Can i remove the stuff to do plugin installation and reinstall it all over again. I have been through forums extensively regarding this. But information regarding uninstall is less mentioned. Please advice. Thank you. Regards, Gokul -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Tue Mar 10 22:31:10 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 10 Mar 2009 22:31:10 -0400 Subject: [Mongrel] error : Redmine In-Reply-To: <2555fb5895b0e2272a9e9ef45cfa32dd@ruby-forum.com> References: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> <2555fb5895b0e2272a9e9ef45cfa32dd@ruby-forum.com> Message-ID: <71166b3b0903101931n797690deq31df23a223c7c8aa@mail.gmail.com> On Tue, Mar 10, 2009 at 8:42 PM, Gokul Cv wrote: > Hello, > > I also find that ?the stuff to do plugin is broken. It seems it has not > been installed correctly. Will this be ?contributing to the error? . > Accessing it displays the same error as mentioned before-- > > Internal error An error occurred on the page you were trying to access. > If you continue to experience problems please contact your redMine > administrator for assistance. > > Can i remove the stuff to do plugin installation and reinstall it all > over again. I have been through forums extensively regarding this. But > information regarding uninstall is less mentioned. Please advice. Thank > you. > You should bring this into a RedMine user lists and not mongrel. Nothing we can't do without the knowledge of the infrastructure you're using or depending on. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From lists at ruby-forum.com Wed Mar 11 13:29:19 2009 From: lists at ruby-forum.com (Gokul Cv) Date: Wed, 11 Mar 2009 18:29:19 +0100 Subject: [Mongrel] error : Redmine In-Reply-To: <71166b3b0903101931n797690deq31df23a223c7c8aa@mail.gmail.com> References: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> <2555fb5895b0e2272a9e9ef45cfa32dd@ruby-forum.com> <71166b3b0903101931n797690deq31df23a223c7c8aa@mail.gmail.com> Message-ID: <2a8307d3d5f0949c7d77b417a883ae13@ruby-forum.com> Hello Luis, Thank you for writing in. I have submitted my post under the 'ruby' forum section. Note that i have also furnished information regarding my infrastructure. Please have a look into this. Thank you. Regards, Gokul. -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Wed Mar 11 16:25:37 2009 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 11 Mar 2009 16:25:37 -0400 Subject: [Mongrel] error : Redmine In-Reply-To: <2a8307d3d5f0949c7d77b417a883ae13@ruby-forum.com> References: <709b4101d6b05e22e678a271e6c17e79@ruby-forum.com> <2555fb5895b0e2272a9e9ef45cfa32dd@ruby-forum.com> <71166b3b0903101931n797690deq31df23a223c7c8aa@mail.gmail.com> <2a8307d3d5f0949c7d77b417a883ae13@ruby-forum.com> Message-ID: <71166b3b0903111325y307eacfge3073f7a5f2e363c@mail.gmail.com> On Wed, Mar 11, 2009 at 1:29 PM, Gokul Cv wrote: > Hello Luis, > > Thank you for writing in. I have submitted my post under the 'ruby' > forum section. Note that i have also furnished information regarding my > infrastructure. Please have a look into this. Thank you. Gokul, That doesn't help me. I'm subscribed to the real mailing list, not the forum bridge of ruby-forum. Please include all the related links and information in the same email so anyone can take a look without doing a search and research to help you out. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From gwolf at gwolf.org Wed Mar 11 13:08:19 2009 From: gwolf at gwolf.org (Gunnar Wolf) Date: Wed, 11 Mar 2009 11:08:19 -0600 Subject: [Mongrel] Allowing for mongrel-cluster to start with different users specified in YAML Message-ID: <20090311170819.GA5261@cajita.gateway.2wire.net> Hi, This issue came to my attention after a bug report against the Debian packaging of mongrel-cluster [1]: The mongrel-cluster startup script, mongrel_cluster_ctl, assumes either it is being run with root privileges (and each of the configured Mongrel services should specify in its configuration file which user it should run as) or it is run under a regular system user (and no configuration files should specify a user to run as). The configuration setup for the Debian package pushed towards the second situation, switching to the regular system-wide web applications user (www-data). However, this situation is suboptimal for many installations - Say, I host several developers' services at my machine and I want each of my Mongrels to run under the given developer UID/GID. So, what I do is to specify in each of the config files the 'user' and 'group' keys. Now, if mongrel_cluster_ctl is called as root, this will succeed - But if a user didn't specify user/group, his process will run as root. Bad situation. Please consider the attached patch (which is the same I sent to the Debian bugtracker, minus the Debian-initscript-specific hunks). It allows for --user and --group options to be given to mongrel_cluster_ctl, specifying the default user and group to run individual Mongrels at, and which are overriden by configuration-supplied entries. The attached patch was made against the current SVN tree, at the root. Greetings, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500424 -- Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -------------- next part -------------- A non-text attachment was scrubbed... Name: mongrel.patch Type: text/x-diff Size: 4515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gtendai at beckman.com Wed Mar 11 19:04:08 2009 From: gtendai at beckman.com (gtendai at beckman.com) Date: Wed, 11 Mar 2009 16:04:08 -0700 Subject: [Mongrel] Geza Tendai/NB/BII is out of the office. Message-ID: I will be out of the office starting 03/04/2009 and will not return until 03/16/2009. I will respond to your message when I return. The server made the following annotations --------------------------------------------------------------------------------- This message contains information that may be privileged or confidential and is the property of Beckman Coulter, Inc. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. --------------------------------------------------------------------------------- From lists at ruby-forum.com Sun Mar 22 01:43:43 2009 From: lists at ruby-forum.com (hwang is) Date: Sun, 22 Mar 2009 06:43:43 +0100 Subject: [Mongrel] hi all ! Message-ID: hi all i'm can't speak english well.... i used not rails webframework. i used camping webframework.. i has something problem. i used gems list is.. mongrel-1.1.5 camping-1.5.180 and update now.. camping-1.9.300 so, My blog looks like an error on the server. my old code is .. 615 if __FILE__ == $0 616 require 'mongrel/camping' 617 618 Conf::Models::Base.establish_connection :adapter => 'sqlite3', :database => 'conf.db' 619 Conf::Models::Base.logger = Logger.new('conf.log') 620 Conf.create 621 622 config = Mongrel::Configurator.new :host => "0.0.0.0" do 623 listener :port => 80 do 624 uri "/", :handler => Mongrel::Camping::CampingHandler.new(Conf) 625 uri "/favicon", :handler => Mongrel::Error404Handler.new("") 626 trap("INT") { stop } 627 run 628 end 629 end 630 631 puts "** http://localhost:80/" 632 t = Time.now 633 @servertime=t 634 puts "?? ?? ?? : #{t.year}?#{t.month}?#{t.day}?#{t.hour}?#{t.min}?#{t.sec}?" 635 config.join 636 end and error code is, his at info105:~$ sudo ruby conf_mongrel1.9.rb ** http://localhost:80/ ?? ?? ?? : 2009?3?22?13?30?25? Sun Mar 22 13:30:31 +0900 2009: Read error: # is not a symbol> (eval):53:in `const_get' (eval):53:in `method_missing' /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:53:in `process' /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:52:in `synchronize' /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:52:in `process' /usr/local/lib/site_ruby/1.8/mongrel.rb:159:in `process_client' /usr/local/lib/site_ruby/1.8/mongrel.rb:158:in `each' /usr/local/lib/site_ruby/1.8/mongrel.rb:158:in `process_client' /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `run' /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `initialize' /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `new' /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `run' /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `initialize' /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `new' /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `run' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:282:in `run' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:281:in `each' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:281:in `run' conf_mongrel1.9.rb:627:in `cloaker_' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:149:in `call' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:149:in `listener' conf_mongrel1.9.rb:623:in `cloaker_' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:50:in `call' /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:50:in `initialize' conf_mongrel1.9.rb:622:in `new' conf_mongrel1.9.rb:622 plz help.. -- Posted via http://www.ruby-forum.com/. From dido.sevilla at gmail.com Tue Mar 24 00:23:34 2009 From: dido.sevilla at gmail.com (Dido Sevilla) Date: Tue, 24 Mar 2009 12:23:34 +0800 Subject: [Mongrel] Bare carriage returns in HTTP headers Message-ID: I've been using Mongrel for a while to write bare HTTP servlets as a replacement for webrick and encountered an HTTP client using the servlet that for some reason occasionally embeds carriage return characters ('\r', 0x0d) inside the value fields of message headers. Mongrel doesn't like that, and aborts the request with a parse error. I'm not sure if this is strictly permitted by RFC 2616, but at any rate, changing Mongrel to accept these kinds of HTTP headers was a single character change in the Ragel parser, viz.: *** START OF PATCH *** Index: http11_parser_common.rl =================================================================== --- http11_parser_common.rl (revision 1037) +++ http11_parser_common.rl (working copy) @@ -46,7 +46,7 @@ field_value = any* >start_value %write_value; - message_header = field_name ":" " "* field_value :> CRLF; + message_header = field_name ":" " "* field_value :>> CRLF; Request = Request_Line ( message_header )* ( CRLF @done ); *** END OF PATCH *** All that was necessary was to simply change the regular expression in the Ragel parser to use a finish-guarded concatenation operator instead of an entry-guarded one as in the original. From a cursory reading of RFC 2616 I don't see that a carriage return character there should be illegal, but as Jon Postel was once quoted as saying: "Be liberal in what you accept, and conservative in what you send." -- ??????????????????????? ???????????????????????????? http://stormwyrm.blogspot.com From rochkind at jhu.edu Tue Mar 24 12:15:51 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Tue, 24 Mar 2009 12:15:51 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: References: Message-ID: <49C90737.6040401@jhu.edu> "Be liberal in what you accept, and conservative in what you send." Sadly (to my perspective), this is definitely not the philosophy of Mongrel, and the mongrel development 'community' (does it exist?) is not partial to it. I've run into other malformed HTTP requests in other circumstances, and the solution I ended up with was using Apache rewrite maps to "fix" those malformed requests before they even get to mongrel. I'm not sure if that solution would work for this particular error, but sounds like you've found another one. I wouldn't hold my breath for that patch to be incorporated in mongrel though, the mongrel philosophy seems to be to be conservative in what it accepts. Jonathan Dido Sevilla wrote: > I've been using Mongrel for a while to write bare HTTP servlets as a > replacement for webrick and encountered an HTTP client using the > servlet that for some reason occasionally embeds carriage return > characters ('\r', 0x0d) inside the value fields of message headers. > Mongrel doesn't like that, and aborts the request with a parse error. > I'm not sure if this is strictly permitted by RFC 2616, but at any > rate, changing Mongrel to accept these kinds of HTTP headers was a > single character change in the Ragel parser, viz.: > > *** START OF PATCH *** > > Index: http11_parser_common.rl > =================================================================== > --- http11_parser_common.rl (revision 1037) > +++ http11_parser_common.rl (working copy) > @@ -46,7 +46,7 @@ > > field_value = any* >start_value %write_value; > > - message_header = field_name ":" " "* field_value :> CRLF; > + message_header = field_name ":" " "* field_value :>> CRLF; > > Request = Request_Line ( message_header )* ( CRLF @done ); > > *** END OF PATCH *** > > All that was necessary was to simply change the regular expression in > the Ragel parser to use a finish-guarded concatenation operator > instead of an entry-guarded one as in the original. From a cursory > reading of RFC 2616 I don't see that a carriage return character there > should be illegal, but as Jon Postel was once quoted as saying: "Be > liberal in what you accept, and conservative in what you send." > > From normalperson at yhbt.net Tue Mar 24 16:26:44 2009 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 24 Mar 2009 13:26:44 -0700 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <49C90737.6040401@jhu.edu> References: <49C90737.6040401@jhu.edu> Message-ID: <20090324202644.GB22684@dcvr.yhbt.net> Jonathan Rochkind wrote: > Dido Sevilla wrote: >> I've been using Mongrel for a while to write bare HTTP servlets as a >> replacement for webrick and encountered an HTTP client using the >> servlet that for some reason occasionally embeds carriage return >> characters ('\r', 0x0d) inside the value fields of message headers. >> Mongrel doesn't like that, and aborts the request with a parse error. >> I'm not sure if this is strictly permitted by RFC 2616, but at any >> rate, changing Mongrel to accept these kinds of HTTP headers was a >> single character change in the Ragel parser, viz.: >> From a cursory >> reading of RFC 2616 I don't see that a carriage return character there >> should be illegal, but as Jon Postel was once quoted as saying: "Be >> liberal in what you accept, and conservative in what you send." "\r" is a control character and is not allowed in field values. This also has the potential to break things with 3rd party libraries and applications because it's not allowed by HTTP. I consider stopping bad things early in the pipeline a good policy: The kernel I use enforces TCP and doesn't allow corrupt IP packets to get to Mongrel. Thus Mongrel doesn't have to worry about bad/malicious TCP traffic. Along the same lines, Mongrel enforces HTTP, so the application doesn't have to worry about non-compliant HTTP traffic at all. > "Be liberal in what you accept, and conservative in what you send." > > Sadly (to my perspective), this is definitely not the philosophy of > Mongrel, and the mongrel development 'community' (does it exist?) is not > partial to it. I believe that philosophy leads to huge compatibility issues down the line. It makes proliferation of a new technology easier and faster ("worse is better"); but HTTP has already "won" as a protocol and fortunately most clients do a pretty good job (unlike with HTML and HTML authors vs parsers). > I've run into other malformed HTTP requests in other circumstances, and > the solution I ended up with was using Apache rewrite maps to "fix" > those malformed requests before they even get to mongrel. I'm not sure > if that solution would work for this particular error, but sounds like > you've found another one. There was a bug we fixed last year where the parser was too strict with certain requests made by IE. Other than that, I don't believe there has been any changes to the way the parser behaves. > I wouldn't hold my breath for that patch to be incorporated in mongrel > though, the mongrel philosophy seems to be to be conservative in what it > accepts. Not speaking for the rest of the team, but I'm very much against this patch. ref: http://mongrel.rubyforge.org/wiki/Security -- Eric Wong From jos at catnook.com Tue Mar 24 17:00:17 2009 From: jos at catnook.com (Jos Backus) Date: Tue, 24 Mar 2009 14:00:17 -0700 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <20090324202644.GB22684@dcvr.yhbt.net> References: <49C90737.6040401@jhu.edu> <20090324202644.GB22684@dcvr.yhbt.net> Message-ID: <20090324210017.GA83480@lizzy.catnook.local> On Tue, Mar 24, 2009 at 01:26:44PM -0700, Eric Wong wrote: > I believe that philosophy leads to huge compatibility issues down the > line. It makes proliferation of a new technology easier and faster > ("worse is better"); but HTTP has already "won" as a protocol and > fortunately most clients do a pretty good job (unlike with HTML and > HTML authors vs parsers). Fwiw, "Be liberal in what you accept, and conservative in what you send." is an awful engineering principle imo, and I strongly agree with Eric here. Working around other code's brokenness wwill just perpetuate it and make things worse in the long run. -- Jos Backus jos at catnook.com From evan at cloudbur.st Tue Mar 24 20:21:33 2009 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 24 Mar 2009 17:21:33 -0700 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <20090324202644.GB22684@dcvr.yhbt.net> References: <49C90737.6040401@jhu.edu> <20090324202644.GB22684@dcvr.yhbt.net> Message-ID: I am ambivalent, so I will defer to Eric. Evan On Tue, Mar 24, 2009 at 1:26 PM, Eric Wong wrote: > Jonathan Rochkind wrote: >> Dido Sevilla wrote: >>> I've been using Mongrel for a while to write bare HTTP servlets as a >>> replacement for webrick and encountered an HTTP client using the >>> servlet that for some reason occasionally embeds carriage return >>> characters ('\r', 0x0d) inside the value fields of message headers. >>> Mongrel doesn't like that, and aborts the request with a parse error. >>> I'm not sure if this is strictly permitted by RFC 2616, but at any >>> rate, changing Mongrel to accept these kinds of HTTP headers was a >>> single character change in the Ragel parser, viz.: > > > >>> From a cursory >>> reading of RFC 2616 I don't see that a carriage return character there >>> should be illegal, but as Jon Postel was once quoted as saying: "Be >>> liberal in what you accept, and conservative in what you send." > > "\r" is a control character and is not allowed in field values. ?This > also has the potential to break things with 3rd party libraries and > applications because it's not allowed by HTTP. > > I consider stopping bad things early in the pipeline a good policy: > > ?The kernel I use enforces TCP and doesn't allow corrupt IP packets to > ?get to Mongrel. ?Thus Mongrel doesn't have to worry about > ?bad/malicious TCP traffic. > > ?Along the same lines, Mongrel enforces HTTP, so the application > ?doesn't have to worry about non-compliant HTTP traffic at all. > >> "Be liberal in what you accept, and conservative in what you send." >> >> Sadly (to my perspective), this is definitely not the philosophy of >> Mongrel, and the mongrel development 'community' (does it exist?) is not >> partial to it. > > I believe that philosophy leads to huge compatibility issues down the > line. ?It makes proliferation of a new technology easier and faster > ("worse is better"); but HTTP has already "won" as a protocol and > fortunately most clients do a pretty good job (unlike with HTML and > HTML authors vs parsers). > >> I've run into other malformed HTTP requests in other circumstances, and >> the solution I ended up with was using Apache rewrite maps to "fix" >> those malformed requests before they even get to mongrel. ?I'm not sure >> if that solution would work for this particular error, but sounds like >> you've found another one. > > There was a bug we fixed last year where the parser was too strict with > certain requests made by IE. ?Other than that, I don't believe there > has been any changes to the way the parser behaves. > >> I wouldn't hold my breath for that patch to be incorporated in mongrel >> though, the mongrel philosophy seems to be to be conservative in what it >> accepts. > > Not speaking for the rest of the team, but I'm very much against this > patch. > > ref: http://mongrel.rubyforge.org/wiki/Security > > -- > Eric Wong > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver From dido.sevilla at gmail.com Thu Mar 26 03:59:59 2009 From: dido.sevilla at gmail.com (Dido Sevilla) Date: Thu, 26 Mar 2009 15:59:59 +0800 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <49C90737.6040401@jhu.edu> References: <49C90737.6040401@jhu.edu> Message-ID: On Wed, Mar 25, 2009 at 12:15 AM, Jonathan Rochkind wrote: > I've run into other malformed HTTP requests in other circumstances, and the > solution I ended up with was using Apache rewrite maps to "fix" those > malformed requests before they even get to mongrel. ?I'm not sure if that > solution would work for this particular error, but sounds like you've found > another one. > Any hints on how I can do this? Obviously I have no control over what hits my HTTP server and must deal with the broken clients as best I can. Ironically, modifying the Mongrel parser to work around this particular broken HTTP client turned out to be a lot easier than sifting through the Apache documentation to find a particular module that would do what needed to be done... > I wouldn't hold my breath for that patch to be incorporated in mongrel > though, the mongrel philosophy seems to be to be conservative in what it > accepts. Neither do I expect it to get incorporated, in spite of its simplicity. The patch does not make me comfortable in the least. By the way, if control characters are not allowed in field values, why does the regex for field_value in the current SVN source have an any* expression rather than a more restrictive class of characters that it can accept? That means that we could put some other control character there and have Mongrel accept it anyway, in spite of its being prohibited by RFC 2616. -- ??????????????????????? ???????????????????????????? http://stormwyrm.blogspot.com From rochkind at jhu.edu Thu Mar 26 11:17:39 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 26 Mar 2009 11:17:39 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: References: <49C90737.6040401@jhu.edu> Message-ID: <49CB9C93.2080600@jhu.edu> My problem was with invalid query strings being sent to me by a vendor, not with problems in the header. So it won't be _exactly_ the same. I'm not sure if an apache rewrite map can change headers or not; it can change path/query string, which is all I needed. But I can show you what I did, in case it gives you ideas. It was a bit of a pain to figure out. Here's the apache.conf I use to deploy my app (actually, this is a Rails erb template for such a file, but you'll figure it out): http://umlaut.rubyforge.org/svn/trunk/lib/generators/mongrel_deploy_files/templates/umlaut_http.conf The parts to pay attention to is just the part that uses a perl script as as an apache 'external rewrite map', here: # We want to re-write URLs with 'bad' < and > chars in the query # string (eg from EBSCO) to escape them. We use a perl script # that came with Umlaut to do that. RewriteEngine on RewriteMap query_escape prg:<%= destination_path('script/umlaut/rewrite_map.pl') %> #RewriteLock /var/lock/subsys/apache.rewrite.lock RewriteCond %{query_string} ^(.*[\>\<].*)$ RewriteRule ^(.*)$ $1?${query_escape:%1} [R,L,NE] And here's the simple Perl script that replaced illegal chars in URL path/query string: http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl Hope that helps, Jonathan Dido Sevilla wrote: > On Wed, Mar 25, 2009 at 12:15 AM, Jonathan Rochkind wrote: > >> I've run into other malformed HTTP requests in other circumstances, and the >> solution I ended up with was using Apache rewrite maps to "fix" those >> malformed requests before they even get to mongrel. I'm not sure if that >> solution would work for this particular error, but sounds like you've found >> another one. >> >> > > Any hints on how I can do this? Obviously I have no control over what > hits my HTTP server and must deal with the broken clients as best I > can. Ironically, modifying the Mongrel parser to work around this > particular broken HTTP client turned out to be a lot easier than > sifting through the Apache documentation to find a particular module > that would do what needed to be done... > > >> I wouldn't hold my breath for that patch to be incorporated in mongrel >> though, the mongrel philosophy seems to be to be conservative in what it >> accepts. >> > > Neither do I expect it to get incorporated, in spite of its > simplicity. The patch does not make me comfortable in the least. > > By the way, if control characters are not allowed in field values, why > does the regex for field_value in the current SVN source have an any* > expression rather than a more restrictive class of characters that it > can accept? That means that we could put some other control character > there and have Mongrel accept it anyway, in spite of its being > prohibited by RFC 2616. > > From normalperson at yhbt.net Thu Mar 26 14:42:40 2009 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 26 Mar 2009 11:42:40 -0700 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: References: <49C90737.6040401@jhu.edu> Message-ID: <20090326184239.GA8956@dcvr.yhbt.net> Dido Sevilla wrote: > On Wed, Mar 25, 2009 at 12:15 AM, Jonathan Rochkind wrote: > > I've run into other malformed HTTP requests in other circumstances, and the > > solution I ended up with was using Apache rewrite maps to "fix" those > > malformed requests before they even get to mongrel. ?I'm not sure if that > > solution would work for this particular error, but sounds like you've found > > another one. > > > > Any hints on how I can do this? Obviously I have no control over what > hits my HTTP server and must deal with the broken clients as best I > can. Ironically, modifying the Mongrel parser to work around this > particular broken HTTP client turned out to be a lot easier than > sifting through the Apache documentation to find a particular module > that would do what needed to be done... > > > I wouldn't hold my breath for that patch to be incorporated in mongrel > > though, the mongrel philosophy seems to be to be conservative in what it > > accepts. > > Neither do I expect it to get incorporated, in spite of its > simplicity. The patch does not make me comfortable in the least. > > By the way, if control characters are not allowed in field values, why > does the regex for field_value in the current SVN source have an any* > expression rather than a more restrictive class of characters that it > can accept? That means that we could put some other control character > there and have Mongrel accept it anyway, in spite of its being > prohibited by RFC 2616. Good question. That's for Zed since he originally created this parser (but I don't think he wants to be bothered about it anymore). Zed probably had his reasons... maybe there are legit/real clients that send invalid bytes we need to let through. But "\r" (and "\n") have more potential to break things than other control chars because it's part of the delimiter sequence that external libraries/apps may not expect. My reverse proxy (nginx) rejects header values with "\r" before it ever gets to Mongrel, however. -- Eric Wong From normalperson at yhbt.net Thu Mar 26 14:53:00 2009 From: normalperson at yhbt.net (Eric Wong) Date: Thu, 26 Mar 2009 11:53:00 -0700 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <49CB9C93.2080600@jhu.edu> References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> Message-ID: <20090326185300.GB8956@dcvr.yhbt.net> Jonathan Rochkind wrote: > My problem was with invalid query strings being sent to me by a vendor, > not with problems in the header. So it won't be _exactly_ the same. I'm > not sure if an apache rewrite map can change headers or not; it can > change path/query string, which is all I needed. But I can show you what > I did, in case it gives you ideas. It was a bit of a pain to figure out. > And here's the simple Perl script that replaced illegal chars in URL > path/query string: > > http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl These two those are no longer needed with the SVN version (which we currently run in production on a pretty heavy site). I think it was IE6 sending them and we can't ignore IE6 :< s/>/%3E/g; s/ References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> <20090326185300.GB8956@dcvr.yhbt.net> Message-ID: <49CBE6C6.20803@jhu.edu> Yes, my vendor is really that brain-damaged. Yes, I have told them that. But I'm not absolutely sure if my vendor ever sends those, it was < and > that I identified, but as long as I was writing the code, and had been told that mongrel insisted on absolute legal URIs and if it wasn't legal by the standard I shouldn't expect mongrel to do anything but refuse it--I might as well catch anything else that could make an illegal URI. But actually, yeah, what they are doing is putting unescaped _xml_ fragments in a url query string. &foo=bar. So yeah, a backslash will be in a query string too. Interesting to me that mongrel no longer chokes on these, since when it was brought up before I was told that there was no way no how that mongrel was ever going to do anything but choke on them. :) If I can find my test cases from my vendor around, I'll see if current mongrels no longer need my workaround, even though you guys told me that would never ever happen. But I run latest ruby gem release, I don't run from svn trunk. Jonathan Eric Wong wrote: > Jonathan Rochkind wrote: > >> My problem was with invalid query strings being sent to me by a vendor, >> not with problems in the header. So it won't be _exactly_ the same. I'm >> not sure if an apache rewrite map can change headers or not; it can >> change path/query string, which is all I needed. But I can show you what >> I did, in case it gives you ideas. It was a bit of a pain to figure out. >> > > >> And here's the simple Perl script that replaced illegal chars in URL >> path/query string: >> >> http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl >> > > These two those are no longer needed with the SVN version (which > we currently run in production on a pretty heavy site). I think > it was IE6 sending them and we can't ignore IE6 :< > > s/>/%3E/g; > s/ > Unfortunately I don't think it made the 1.1.5 release > > http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996 > > I don't think I ever saw Mongrel error out on these. Is your vendor > really that brain damaged? > s/\//%2F/g; > s/\\/%5C/g; > > But man, this just creeps me out: > s/ /\+/g; > > ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :) > > From rochkind at jhu.edu Thu Mar 26 16:41:23 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 26 Mar 2009 16:41:23 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <20090326185300.GB8956@dcvr.yhbt.net> References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> <20090326185300.GB8956@dcvr.yhbt.net> Message-ID: <49CBE873.2000008@jhu.edu> Oh, and PS, I know that IE6 sends those. Because I discovered it. Safari does too, for that matter. If they are (illegaly) in a URL in HTML or entered in the location bar, etc. My particular case in fact involved URLs in HTML (produced by a third party, but targetting my app) delivered to an ordinary user agent like IE6 or Firefox or Safari. Firefox would happily correct them before sending them to the server. IE6 and Safari, no. This is what I reported like a year and a half ago, and was told it wasn't mongrel's problem. And brought up again like four months ago, to see if with different developers you'd have a different opinion, and was again told it wasn't mongrel's problem. I guess someone with more pull than me found it inconvenient? Jonathan Eric Wong wrote: > Jonathan Rochkind wrote: > >> My problem was with invalid query strings being sent to me by a vendor, >> not with problems in the header. So it won't be _exactly_ the same. I'm >> not sure if an apache rewrite map can change headers or not; it can >> change path/query string, which is all I needed. But I can show you what >> I did, in case it gives you ideas. It was a bit of a pain to figure out. >> > > >> And here's the simple Perl script that replaced illegal chars in URL >> path/query string: >> >> http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl >> > > These two those are no longer needed with the SVN version (which > we currently run in production on a pretty heavy site). I think > it was IE6 sending them and we can't ignore IE6 :< > > s/>/%3E/g; > s/ > Unfortunately I don't think it made the 1.1.5 release > > http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996 > > I don't think I ever saw Mongrel error out on these. Is your vendor > really that brain damaged? > s/\//%2F/g; > s/\\/%5C/g; > > But man, this just creeps me out: > s/ /\+/g; > > ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :) > > From rossfsinger at gmail.com Thu Mar 26 22:10:09 2009 From: rossfsinger at gmail.com (Ross Singer) Date: Thu, 26 Mar 2009 22:10:09 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <49CBE873.2000008@jhu.edu> References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> <20090326185300.GB8956@dcvr.yhbt.net> <49CBE873.2000008@jhu.edu> Message-ID: <23b83f160903261910w38823ac7v6f6ef875adbfba40@mail.gmail.com> Actually, I think the condition was that these URLs were being created in Javascript and injected into the location header. I'm not sure that either of these browsers (IE or Safari) don't do the right thing when < or > are entered in the location bar. I do know for a fact, however, that the condition Jonathan is talking about is because the vendor is doing a redirect in javascript (because I first brought it up 2 1/2 years ago: http://thread.gmane.org/gmane.comp.lang.ruby.mongrel.general/1107/focus=1179). -Ross. On Thu, Mar 26, 2009 at 4:41 PM, Jonathan Rochkind wrote: > Oh, and PS, I know that IE6 sends those. Because I discovered it. Safari > does too, for that matter. If they are (illegaly) in a URL in HTML or > entered in the location bar, etc. > My particular case in fact involved URLs in HTML (produced by a third party, > but targetting my app) delivered to an ordinary user agent like IE6 or > Firefox or Safari. ?Firefox would happily correct them before sending them > to the server. ?IE6 and Safari, no. > > This is what I reported like a year and a half ago, and was told it wasn't > mongrel's problem. And brought up again like four months ago, to see if with > different developers you'd have a different opinion, and was again told it > wasn't mongrel's problem. > > I guess someone with more pull than me found it inconvenient? > > Jonathan > > Eric Wong wrote: >> >> Jonathan Rochkind wrote: >> >>> >>> My problem was with invalid query strings being sent to me by a vendor, >>> ?not with problems in the header. So it won't be _exactly_ the same. I'm >>> ?not sure if an apache rewrite map can change headers or not; it can ?change >>> path/query string, which is all I needed. But I can show you what ?I did, in >>> case it gives you ideas. It was a bit of a pain to figure out. >>> >> >> >>> >>> And here's the simple Perl script that replaced illegal chars in URL >>> ?path/query string: >>> >>> http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl >>> >> >> These two those are no longer needed with the SVN version (which >> we currently run in production on a pretty heavy site). ?I think >> it was IE6 sending them and we can't ignore IE6 :< >> >> ? ? ? ?s/>/%3E/g; >> ? ? ? ?s/> >> Unfortunately I don't think it made the 1.1.5 release >> >> >> ?http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996 >> >> I don't think I ever saw Mongrel error out on these. ?Is your vendor >> really that brain damaged? >> ? ? ? ?s/\//%2F/g; >> ? ? ? ?s/\\/%5C/g; >> >> But man, this just creeps me out: >> ?s/ /\+/g; >> >> ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :) >> >> > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From rochkind at jhu.edu Fri Mar 27 11:49:25 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Fri, 27 Mar 2009 11:49:25 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <23b83f160903261910w38823ac7v6f6ef875adbfba40@mail.gmail.com> References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> <20090326185300.GB8956@dcvr.yhbt.net> <49CBE873.2000008@jhu.edu> <23b83f160903261910w38823ac7v6f6ef875adbfba40@mail.gmail.com> Message-ID: <49CCF585.900@jhu.edu> I tested it out in IE with manually entering it in the location bar. At least in IE6, if you enter a < manually in a query string in the location bar, IE will send it along in the HTTP request as is, without escaping it. (Which made it a lot easier to create a test case to make sure I had it taken care of!) Ross Singer wrote: > Actually, I think the condition was that these URLs were being created > in Javascript and injected into the location header. I'm not sure > that either of these browsers (IE or Safari) don't do the right thing > when < or > are entered in the location bar. I do know for a fact, > however, that the condition Jonathan is talking about is because the > vendor is doing a redirect in javascript (because I first brought it > up 2 1/2 years ago: > http://thread.gmane.org/gmane.comp.lang.ruby.mongrel.general/1107/focus=1179). > > -Ross. > > On Thu, Mar 26, 2009 at 4:41 PM, Jonathan Rochkind wrote: > >> Oh, and PS, I know that IE6 sends those. Because I discovered it. Safari >> does too, for that matter. If they are (illegaly) in a URL in HTML or >> entered in the location bar, etc. >> My particular case in fact involved URLs in HTML (produced by a third party, >> but targetting my app) delivered to an ordinary user agent like IE6 or >> Firefox or Safari. Firefox would happily correct them before sending them >> to the server. IE6 and Safari, no. >> >> This is what I reported like a year and a half ago, and was told it wasn't >> mongrel's problem. And brought up again like four months ago, to see if with >> different developers you'd have a different opinion, and was again told it >> wasn't mongrel's problem. >> >> I guess someone with more pull than me found it inconvenient? >> >> Jonathan >> >> Eric Wong wrote: >> >>> Jonathan Rochkind wrote: >>> >>> >>>> My problem was with invalid query strings being sent to me by a vendor, >>>> not with problems in the header. So it won't be _exactly_ the same. I'm >>>> not sure if an apache rewrite map can change headers or not; it can change >>>> path/query string, which is all I needed. But I can show you what I did, in >>>> case it gives you ideas. It was a bit of a pain to figure out. >>>> >>>> >>> >>>> And here's the simple Perl script that replaced illegal chars in URL >>>> path/query string: >>>> >>>> http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl >>>> >>>> >>> These two those are no longer needed with the SVN version (which >>> we currently run in production on a pretty heavy site). I think >>> it was IE6 sending them and we can't ignore IE6 :< >>> >>> s/>/%3E/g; >>> s/>> >>> Unfortunately I don't think it made the 1.1.5 release >>> >>> >>> http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996 >>> >>> I don't think I ever saw Mongrel error out on these. Is your vendor >>> really that brain damaged? >>> s/\//%2F/g; >>> s/\\/%5C/g; >>> >>> But man, this just creeps me out: >>> s/ /\+/g; >>> >>> ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :) >>> >>> >>> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From rossfsinger at gmail.com Fri Mar 27 13:26:17 2009 From: rossfsinger at gmail.com (Ross Singer) Date: Fri, 27 Mar 2009 13:26:17 -0400 Subject: [Mongrel] Bare carriage returns in HTTP headers In-Reply-To: <49CCF585.900@jhu.edu> References: <49C90737.6040401@jhu.edu> <49CB9C93.2080600@jhu.edu> <20090326185300.GB8956@dcvr.yhbt.net> <49CBE873.2000008@jhu.edu> <23b83f160903261910w38823ac7v6f6ef875adbfba40@mail.gmail.com> <49CCF585.900@jhu.edu> Message-ID: <23b83f160903271026p7436616ct63ee910b067c554f@mail.gmail.com> Well, so much for benefit of the doubt... -Ross. On Fri, Mar 27, 2009 at 11:49 AM, Jonathan Rochkind wrote: > I tested it out in IE with manually entering it in the location bar. At > least in IE6, if you enter a < manually in a query string in the location > bar, IE will send it along in the HTTP request as is, without escaping it. > > (Which made it a lot easier to create a test case to make sure I had it > taken care of!) > > Ross Singer wrote: >> >> Actually, I think the condition was that these URLs were being created >> in Javascript and injected into the location header. ?I'm not sure >> that either of these browsers (IE or Safari) don't do the right thing >> when < or > are entered in the location bar. ?I do know for a fact, >> however, that the condition Jonathan is talking about is because the >> vendor is doing a redirect in javascript (because I first brought it >> up 2 1/2 years ago: >> >> http://thread.gmane.org/gmane.comp.lang.ruby.mongrel.general/1107/focus=1179). >> >> -Ross. >> >> On Thu, Mar 26, 2009 at 4:41 PM, Jonathan Rochkind >> wrote: >> >>> >>> Oh, and PS, I know that IE6 sends those. Because I discovered it. Safari >>> does too, for that matter. If they are (illegaly) in a URL in HTML or >>> entered in the location bar, etc. >>> My particular case in fact involved URLs in HTML (produced by a third >>> party, >>> but targetting my app) delivered to an ordinary user agent like IE6 or >>> Firefox or Safari. ?Firefox would happily correct them before sending >>> them >>> to the server. ?IE6 and Safari, no. >>> >>> This is what I reported like a year and a half ago, and was told it >>> wasn't >>> mongrel's problem. And brought up again like four months ago, to see if >>> with >>> different developers you'd have a different opinion, and was again told >>> it >>> wasn't mongrel's problem. >>> >>> I guess someone with more pull than me found it inconvenient? >>> >>> Jonathan >>> >>> Eric Wong wrote: >>> >>>> >>>> Jonathan Rochkind wrote: >>>> >>>> >>>>> >>>>> My problem was with invalid query strings being sent to me by a vendor, >>>>> ?not with problems in the header. So it won't be _exactly_ the same. >>>>> I'm >>>>> ?not sure if an apache rewrite map can change headers or not; it can >>>>> ?change >>>>> path/query string, which is all I needed. But I can show you what ?I >>>>> did, in >>>>> case it gives you ideas. It was a bit of a pain to figure out. >>>>> >>>>> >>>> >>>> >>>>> >>>>> And here's the simple Perl script that replaced illegal chars in URL >>>>> ?path/query string: >>>>> >>>>> http://umlaut.rubyforge.org/svn/trunk/script/umlaut/rewrite_map.pl >>>>> >>>>> >>>> >>>> These two those are no longer needed with the SVN version (which >>>> we currently run in production on a pretty heavy site). ?I think >>>> it was IE6 sending them and we can't ignore IE6 :< >>>> >>>> ? ? ? s/>/%3E/g; >>>> ? ? ? s/>>> >>>> Unfortunately I don't think it made the 1.1.5 release >>>> >>>> >>>> >>>> ?http://mongrel.rubyforge.org/browser/trunk/ext/http11/http11_parser.c?rev=996 >>>> >>>> I don't think I ever saw Mongrel error out on these. ?Is your vendor >>>> really that brain damaged? >>>> ? ? ? s/\//%2F/g; >>>> ? ? ? s/\\/%5C/g; >>>> >>>> But man, this just creeps me out: >>>> ?s/ /\+/g; >>>> >>>> ps: "tr/ /+/;" should be a tick faster than "s/ /\+/g;" :) >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Mongrel-users mailing list >>> Mongrel-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/mongrel-users >>> >>> >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >