Do you know where your variables are? | |
PerlMonks |
Re^3: Does CGI::Application expose a HTTP::Request object?by jaldhar (Vicar) |
on Aug 11, 2010 at 03:52 UTC ( [id://854210]=note: print w/replies, xml ) | Need Help?? |
The value of $header doesn't seem to work for HTTP::Request, it complains with "Bad header argument". Further, it doesn't seem to hold the headers of the request, but of the response CGI::Application is about to deliver, for example in my test it held a "Content-Type: text/html" header. That should have been @{ $self->header_props } because HTTP::Request wants a reference to an array of key-value pairs but in any case it wouldn't work because as you pointed out, it gives outgoing headers not incoming. You would have to get the special HTTP envvars out of the environment and make them into headers. Your elaborate attempts to get the $content *of the request* do not seem to work. None of my tests showed the request content getting through. my @params = $q->param should return all parameters but is empty except for those keys passed in $ENV{QUERY_STRING}, no PUTDATA etc. there. Is a CGI::Fast + CGI::Application based script aware of request data which is not coming from POST requests - at all? As I alluded to in my last reply, I think the problem is POSTDATA and PUTDATA don't get set in some cases. (They are not real params but specially set up by CGI.pm) I think this happens if the MIME type is application/x-www-form-urlencoded or multipart/form-data which is usual for an HTML form. So in this case or if we can't get the them for any other reason, we should read from standard input based on the Content-Length header (which doesn't seem to have CGI.pm method I don't know why.) Try this. Again untested I'm afraid.
--
In Section
Seekers of Perl Wisdom
|
|