in reply to Are all .cgi helper modules unfit for http methods common in REST?

Check out REST Webservices and CGI.pm ... CGI should be handling PUT and POST (and DELETE and GET) correctly. Can you provide code examples? As for PROPFIND ... meh ... I would vote against polluting CGI with support for it (but that's not my call). As for not having an account to submit bugs, come on it takes about 30 second to create a bitcard account.

-derby

Update: Okay missed the link to REST Webservices and CGI.pm (it was more work to write it up than actually create a patch) ... code please ... and failing test cases.

  • Comment on Re: Are all .cgi helper modules unfit for http methods common in REST?

Replies are listed 'Best First'.
Re^2: Are all .cgi helper modules unfit for http methods common in REST?
by isync (Hermit) on Aug 12, 2010 at 20:18 UTC
    Edited my post to include this node while you wrote your post...

    You are right with bitcard, but who wants all these bug reports from a noob who is now banging his head against the wall for two days before finding out that these proven decade-old modules were the initial bug that caused endless rewrites, commenting in/out, design changes, etc.
    My strategy is to hope that the (active) module maintainers follow discussion here anyway and they are best to decide if what I am observing is a bug, or simply incompetence.
[reply]

      Gotcha. Okay ... I normally use bare-bones CGI::Application and do something like this: 

      package MyApp;

use base 'CGI::Application';

....

sub setup {
  my $self = shift;
  my $cgi  = $self->query();

  $self->start_mode( $cgi->request_method() );

  $self->run_modes(
    'PUT'       => 'create',
    'GET'       => 'retrieve',
    'POST'      => 'update',
    'DELETE'    => 'delete',
    'AUTOLOAD'  => 'method_not_supported'
  );
 
  return;  
}

....

1;

      [download]
      I have no idea if PROPFIND would work or not (I'm pretty much WebDAV ignorant). I do believe you still have problems with marshalling (CGI will try to copy that 2G POST/PUT into a scalar and that will probably not go well.

      -derby
[reply]
[d/l]
Re^2: Are all .cgi helper modules unfit for http methods common in REST?
by isync (Hermit) on Aug 12, 2010 at 20:22 UTC
    Puh, test scripts basically done. Still, the test-server seems to refuse to serve PROPFIND requests. I don't know if this is HTTP::Server::Simple or something else, yet. But again - this "we don't like lesser known methods" sucks..

    What already can be observed is that CGI.pm strangely parses PUT data into a 'keywords' param(). (??)

    Minor update to the code: uncommenting the CGI::Simple part should enable you to see how CGI::Simple beahves, but for me it simply hangs. I'm giving up for today...

    test-client.pl
    Read more... (3 kB)
[reply]
[d/l]
[select]

      If you're getting keyword set when processing a PUT request than your code (or HTTP::Request) is setting the content-type of the request to either multipart/form-data or application/x-www-form-urlencoded. You should set the content-type to something else (maybe text/xml).

      -derby
[reply]
        That makes sense. So my requests were faulty.. 1:0 for CGI.pm
[reply]
        Tested this with my test-client.pl script here, and as you said, doing PUTs with a proper header does lead to CGI.pm parsing out PUTPARAM. (As a sidenote, what will CGI.pm parse out on other methods like PROPFIND? PROPFINDDATA??)

        Problem is, if you intend to use this all here for WebDAV, you can't control the clients behaving nicely. For example, gvfs, GNOME's DAV client - as I see it - does not set any headers on requests...
        Read more... (4 kB)
[reply]
[d/l]

In Section Seekers of Perl Wisdom