Good find! 1. If you run that on a real HTTP server (Apache, Nginx etc.) it will just ignore it. Remember that Mongrel/Thin should be served behind a proxy and are "lazy" about checking valid request.
2. A cool thing with the Rack-rewrite is that you can use Rack::Lint to validate the request/response according to the Rack-spec. So that will just raise: Rack::Lint::LintError: REQUEST_METHOD unknown: FOO 3. I'm adding Rack::Lint as a middleware in bin/camping such that it's "safe" in development. If you're running Mongrel/Thin without proxy (madness!), you should also use Rack::Lint. Do you think we should add a protection inside Camping too? On Fri, May 23, 2008 at 6:46 AM, Bluebie, Jenna <[EMAIL PROTECTED]> wrote: > We've just come across an issue for consideration. I am avoiding some words > which would allow people to find this message in an internet search who have > questionable intentions, but wish to communicate a strong sense of caution. > Consider someone who adds extra methods to their controller which they use > in their main get/post methods to do things or to get secret data. Consider > now, this http request: > > FOO / HTTP/1.1 > > And consider that camping allows methods to return a string and have that > returned as a body. This could make for a lovely convenient form of RPC, but > to those unaware, it seems there could be negative results. Aria has > discovered with some testing that it is also possible to access helper > methods remotely in this way, which is especially worth consideration as > some of us use helper methods to do important things, and do not expect them > to be directly accessible to the outside world. > In my own app, I will be using a service to filter all requests which don't > use a standard http method. I'd like to suggest that in the next release of > camping, we could do something like return unless ['GET', 'POST', 'DELETE', > 'HEAD'].include?(request_method), perhaps in the run method of camping. Or > maybe we could raise an error. I'd also appreciate it if this update were > deployed to rubygems servers without haste. I'll be sure to post the service > I write to work around this issue just as soon as I'm done writing it. > > — > Thoughtful Pony > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -- Magnus Holm _______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
