Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
I feel like this is making a mountain out of a mole hill right now. I went to
great lengths to make this contribution as small as possible and dependency
free in hopes of getting this put thru without a lot of hassle. That hasn't
worked here though.
So what are the objections and can it get out of pull request limbo?
tim/
Sent from my iPhone
On Jul 1, 2011, at 2:55, Jaldhar H. Vyas jald...@braincells.com wrote:
On Thu, 30 Jun 2011, Mark Stosberg wrote:
How would you recommend he use REST::Util here. His diff is only a few
lines and does very little. See it here:
https://github.com/tima/CGI--Application--Dispatch/commit/1e906a01f9470b3b15894e4c77e10c0e8468c86b
This bit:
if($tunneling $http_method eq 'POST') {
$rm = sub {
my $self = shift;
my $rest_method = $self-query-param('_method') ||
'POST';
$rest_method = lc $rest_method if $method_lc;
return $rm.'_'.$rest_method;
};
} else {
$http_method = lc $http_method if $method_lc;
$rm .= _$http_method;
}
could be replaced by:
if($tunneling $http_method eq 'POST') {
my $rest_method = request_method($self-query);
$rest_method = lc $rest_method if $method_lc;
return $rm.'_'.$rest_method;
} else {
$http_method = lc $http_method if $method_lc;
$rm .= _$http_method;
}
}
This gets you a wider variety of tunneling behaviors. (see the docs for
request_method in REST::Utils)
The bigger win would be to enable C::A::Dispatch to dispatch based on MIME
type but that would require a more invasive patch.
--
Jaldhar H. Vyas jald...@braincells.com
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Friday, May 20, 2011 at 6:32 PM, Ron Savage wrote: It's sad to hear you refer to that code as 'the mess'. Yes Ron it makes us sad too, but MT(OS) has code that is almost 10 years old and was developed by dozens of engineers with little continuity in a closed sourced environment under some impossible deadlines. That being said, MT/Melody does a lot and has proven to be pretty solid software with a significant latent user base. Our biggest issues are in moving it forward with poor documentation and hacks on top of hacks spaghetti code with breaks kept to a minimum. We are dedicated to refactoring the code and rapidly moving it to where it should be. We are also resigned to this taking a lot of time and effort that we have to grin and bear it while that happens. Melody's community by proxy of MT is that most are not very technical so there are precious few Perl coding resource contributing at this point. (hint. hint.) I often wonder where Melody is heading. Well I could fill your ear on that, but I'd bore everyone to death here. Here are a few summary points in regards to its architecture: * Replace the systems cgi-app-like framework with the real thing, CGI::Application. There were some incompatibilities with cgi-app that MarkStos identified for us. We deprecated those in 1.0 and have inserted suitable warnings and docs. In a version or two we will make the break and will be free to implement CA. * More REST (hence CAD) to support an every increasing amount of jQuery powered AJAX interactions in the UI. * Replace proprietary subsystems and frameworks with common CPAN packages when ever possible. * Any of the above without a suitable CPAN replacement should be refactored in to its own distro and put in to CPAN. * Move to PSGI/Plack Hope that helps. Let me know if you have any additional questions or comments about Melody. tim/ -- Timothy Appnel Principal, The Appnel Group, http://appnel.com/ Director, Open Melody Software Group, http://openmelody.org # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
Hi Tim On Thu, 2011-05-26 at 17:06 -0400, Timothy Appnel wrote: On Friday, May 20, 2011 at 6:32 PM, Ron Savage wrote: It's sad to hear you refer to that code as 'the mess'. Yes Ron it makes us sad too, but MT(OS) has code that is almost 10 years old and was developed by dozens of engineers with little continuity in a closed sourced environment under some impossible deadlines. That being said, MT/Melody does a lot and has proven to be pretty solid software with a significant latent user base. Our biggest issues are in moving it forward with poor documentation and hacks on top of hacks spaghetti code with breaks kept to a minimum. We are dedicated to refactoring the code and rapidly moving it to where it should be. We are also resigned to this taking a lot of time and effort that we have to grin and bear it while that happens. Melody's community by proxy of MT is that most are not very technical so there are precious few Perl coding resource contributing at this point. (hint. hint.) I often wonder where Melody is heading. Well I could fill your ear on that, but I'd bore everyone to death here. Here are a few summary points in regards to its architecture: * Replace the systems cgi-app-like framework with the real thing, CGI::Application. There were some incompatibilities with cgi-app that MarkStos identified for us. We deprecated those in 1.0 and have inserted suitable warnings and docs. In a version or two we will make the break and will be free to implement CA. * More REST (hence CAD) to support an every increasing amount of jQuery powered AJAX interactions in the UI. * Replace proprietary subsystems and frameworks with common CPAN packages when ever possible. * Any of the above without a suitable CPAN replacement should be refactored in to its own distro and put in to CPAN. * Move to PSGI/Plack Hope that helps. Let me know if you have any additional questions or comments about Melody. Thanx for that. I haven't looked at the code, so didn't understand the nature of the problems, which - as we all know - occur all to frequently in long-standing projects. There's always tension between building on pre-existing code and a clean break. It's not a pleasant choice, given the number of factors which apply. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
What in C::A::P::REST would require you to do that? I work with Melody, a community for of Movable Type and we already have a couple of dozen of app modules and probably a hundred run modes. We need a dispatching mechanism in front of CGI::App and not in it to avoid loading anything we don't need. [This is not the case currently with the mess we inherited, but that is where we are committed to going with the code.] tim/ -- Timothy Appnel Principal, The Appnel Group, http://appnel.com/ Director, Open Melody Software Group, http://openmelody.org # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
Hi Tim On Fri, 2011-05-20 at 11:28 -0400, Timothy Appnel wrote: What in C::A::P::REST would require you to do that? I work with Melody, a community for of Movable Type and we already have a couple of dozen of app modules and probably a hundred run modes. We need a dispatching mechanism in front of CGI::App and not in it to avoid loading anything we don't need. [This is not the case currently with the mess we inherited, but that is where we are committed to going with the code.] It's sad to hear you refer to that code as 'the mess'. I often wonder where Melody is heading. That complexity is precisely why I'm so wary when people suggest replacing the current wiki 'with something written in CGI::App'. If they know what they're talking about, fine, but if not... My biggest project was written before I learned of CGI::Application::Dispatch, so I have some understanding of what you're going thru. Once my app was running, featureitis took over. Some pages had 1,500 or more links. Ok, so they're automatically generated lines of output (uni staff list search result), but it's a PITA. Now, I never write an app without C::A::D, and it's always combined with MVC style module design. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Mon, May 16, 2011 at 8:40 AM, Mark Stosberg m...@summersault.com wrote: I like the idea having the REST functionality available through a plugin, and Jaldhar's functionality looks fairly complete, including tunneling, although that's a bit hard to discover now. While I am a proponent of plugins in general I'm not sure about that here. It's just practical and making things more difficult than they need to be based on principal. Perhaps I'm missing something some significant benefit I'm missing. CAD has REST functionality already. So it made sense to make what is a minor extension to that because it was the most practical and the path of least resistance. I also believe that REST tunneling is a dispatching function, not an app one. I don't want to have to load an app class just to figure out if it which run mode I need to call. That makes writing efficient code and managing an app with hundreds of potential run modes -- like say Melody -- a messy affair. I just don't get the logic behind this proposal and need to be convinced otherwise. tim/ -- Timothy Appnel Principal, The Appnel Group, http://appnel.com/ Director, Open Melody Software Group, http://openmelody.org # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Thu, 19 May 2011, Timothy Appnel wrote: While I am a proponent of plugins in general I'm not sure about that here. It's just practical and making things more difficult than they need to be based on principal. Perhaps I'm missing something some significant benefit I'm missing. CAD has REST functionality already. So it made sense to make what is a minor extension to that because it was the most practical and the path of least resistance. I also believe that REST tunneling is a dispatching function, not an app one. Well C::A::P::REST also does tunneling in the context of dispatch. Your problem is you already have a nice, working dispatcher so you don't want to switch to a new one just to get some extra goodies. In that case it would make sense to add functionality to C::A::Dispatch (though I recommend you just switch ;-) All I have to add is that you should use REST::Utils instead of all new code. You would also get MIME Media Type based matching in the process. I don't want to have to load an app class just to figure out if it which run mode I need to call. What in C::A::P::REST would require you to do that? -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Mon, 16 May 2011, Mark Stosberg wrote: Tim Jaldhar I like the idea having the REST functionality available through a plugin, and Jaldhar's functionality looks fairly complete, including tunneling, although that's a bit hard to discover now. Given this, do either of you still have changes you recommend to ::Dispatch to improve the REST experience with CGI::Application? Well, I think this would have to go into CGI::Application itself not dispatch but in my plugin I have a method called rest_error_mode. The main reason this seeming redundancy exists is because CGI::Apps error_mode is only used after the run mode has already been set (see sub __get_body) so it cannot be used if there is an error in the dispatch process itself. Perhaps the fix could be as simple as moving the call to __get_runmeth into the eval but I'm sure you understand all the ramifications better than me. -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On 05/11/2011 10:16 PM, Jaldhar H. Vyas wrote: On Wed, 11 May 2011, Mark Stosberg wrote: Jaldhar, Could point out specifically where your auto-tunneling feature is in the plugin? Oops. The tunneling code is actually in REST::Utils which C::A::P::REST depends on. Here is the POD from that module. Tim Jaldhar I like the idea having the REST functionality available through a plugin, and Jaldhar's functionality looks fairly complete, including tunneling, although that's a bit hard to discover now. Given this, do either of you still have changes you recommend to ::Dispatch to improve the REST experience with CGI::Application? Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] REST tunneling in CGI::Application::Dispatch
Forwarded message: From: Timothy Appnel t...@appnel.com To: CGI Application cgiapp@lists.erlbaum.net Date: Tuesday, May 10, 2011 2:38:03 PM Subject: REST tunneling in CGI::Application::Dispatch I've started a branch to implement REST tunneling in CGI::Application::Dispatch and wanted to post it here for some comment while its still in progress. Here is the issue as described in RESTful Web Services book: http://is.gd/8PSPLE Not all clients support HTTP PUT and DELETE. The action of an XHTML 4 form can only be GET or POST, and this had made a lot of people think that PUT and DELETE aren't real HTTP methods. Some firewalls block HTTP PUT and DELETE but not POST. If the server supports it, a client can get around these limitations by tunneling PUT and DELETE requests through overloaded POST. There's no reason these techniques can't work with other HTTP actions like HEAD, but PUT and DELETE are the most common.What I've started implementing is essentially this: I recommend a tunneling technique pioneered by today's most RESTful web frameworks: include the real HTTP method in the query string. Ruby on Rails defines a hidden form field called '_method' which references the real HTTP method. I've implemented a new boolean parameter auto_rest_tunneling that when true, will get its real HTTP method from the '_method' if one exists. To do that was a bit tricky though because at the spot where the run mode is determined, the application class has not been instantiated to read that parameter with its designated CGI object. I was trying to keep my changes to a minimum so I settled on creating a subroutine that mode_param can use to complete the tunneling if dispatch detects a possible REST tunneling situation. This REST tunneling routine is passed on to the private _run_app method where I had to add a bit of logic so that routine doesn't build the generic mode_param subroutine over top of it. Besides getting some general feedback I had one specific question to where I'm at here: https://github.com/tima/CGI--Application--Dispatch/commit/1e906a01f9470b3b15894e4c77e10c0e8468c86b [BTW: I sent this message to Mike and Mark in advance. Mark requested links to other implementations which I provided in the commit notes.] In line 705 (was line 690) of my addition there is a check for illegal characters in the run mode. This doesn't work when REST tunneling is being used so I added the logic to skip that. Is that going to be a problem? I was thinking of moving that logic out of _run_app and ahead of auto_rest functions in the dispatch sub. Perhaps I missing a case where that is necessary. If I can make that move and not break anything the mode_param sub routine generation could be consolidated in to the dispatch method also. Enough from me. Thoughts? tim/ -- Timothy Appnel Principal, The Appnel Group, http://appnel.com/ Director, Open Melody Software Group, http://openmelody.org # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Wed, 11 May 2011, Timothy Appnel wrote: Forwarded message: From: Timothy Appnel t...@appnel.com To: CGI Application cgiapp@lists.erlbaum.net Date: Tuesday, May 10, 2011 2:38:03 PM Subject: REST tunneling in CGI::Application::Dispatch I know I keep tooting my own horn but all this and more is already present in CGI-Application-Plugin-REST. -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
Hi Tim Just glancing at the code: If you call lc at line 399, surely the check 2 lines down should be for 'post', not 'POST'? Or am I missing something? -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
I know I keep tooting my own horn but all this and more is already present in CGI-Application-Plugin-REST. Jaldhar, Could point out specifically where your auto-tunneling feature is in the plugin? You may want to add the keyword tunneling somewhere in the docs near where you document that feature. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On 05/11/2011 07:47 PM, Ron Savage wrote: Hi Tim Just glancing at the code: If you call lc at line 399, surely the check 2 lines down should be for 'post', not 'POST'? Or am I missing something? It looks like you are looking at the line 399 that shows up on the side of the patch for lines being removed: $http_method = lc $http_method if $method_lc; So, that line is not part of the proposed solution. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
Hi Mark On Wed, 2011-05-11 at 19:56 -0400, Mark Stosberg wrote: On 05/11/2011 07:47 PM, Ron Savage wrote: Hi Tim Just glancing at the code: If you call lc at line 399, surely the check 2 lines down should be for 'post', not 'POST'? Or am I missing something? It looks like you are looking at the line 399 that shows up on the side of the patch for lines being removed: $http_method = lc $http_method if $method_lc; So, that line is not part of the proposed solution. OK. Thanx. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] REST tunneling in CGI::Application::Dispatch
On Wed, 11 May 2011, Mark Stosberg wrote: Jaldhar, Could point out specifically where your auto-tunneling feature is in the plugin? Oops. The tunneling code is actually in REST::Utils which C::A::P::REST depends on. Here is the POD from that module. =head3 request_method($cgi) This function returns the query's HTTP request method. Example 1: my $method = request_method($cgi); This function takes a LCGI or compatible object as its first parameter. Because many web sites don't allow the full set of HTTP methods needed for REST, you can tunnel methods through CGET or CPOST requests in the following ways: In the query with the C_method parameter. This will work even with CPOST requests where parameters are usually passed in the request body. Example 2: http://localhost/index.cgi?_method=DELETE Or with the CX-HTTP-Method-Override HTTP header. Example 3: X-HTTP-METHOD-OVERRIDE: PUT if more than one of these are present, the HTTP header will override the query parameter, which will override the real method. Any method can be tunneled through a CPOST request. Only CGET and CHEAD can be tunneled through a CGET request. You cannot tunnel through a CHEAD, CPUT, CDELETE, or any other request. If an invalid tunnel is attempted, it will be ignored. =cut You may want to add the keyword tunneling somewhere in the docs near where you document that feature. Yes I will add it to the docs for the next version of C::A::P::REST. -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
