cgi_register_parse_cb(3) [debian man page]
cgi_register_parse_cb(3) cgi/cgi.h cgi_register_parse_cb(3) NAME
cgi_register_parse_cb - Register a parse callback SYNOPSIS
#include <cgi/cgi.h> NEOERR *cgi_register_parse_cb(CGI *cgi, const char *method, const char *ctype, void *rock, CGI_PARSE_CB parse_cb); ARGUMENTS
cgi - a CGI struct method - the HTTP method you want to handle, or * for all ctype - the HTTP Content-Type you want to handle, or * for all rock - opaque data that we'll pass to your call back DESCRIPTION
The ClearSilver CGI Kit has built-in functionality to handle the following methods: GET -> doesn't have any data except query string, which is processed for all methods POST w/ application/x-www-form-urlencoded POST w/ multipart/form-data processed as RFC2388 data into files and HDF (see cgi_filehandle()) PUT (any type) The entire data chunk is stored as a file, with meta data in HDF (similar to single files in RFC2388). The data is accessible via cgi_filehandle with NULL for name. To handle other methods/content types, you have to register your own parse function. This isn't necessary if you aren't expecting any data, and technically HTTP only allows data on PUT/POST requests (and presumably user defined methods). In particular, if you want to implement XML-RPC or SOAP, you'll have to register a callback here to grab the XML data chunk. Usually you'll want to register POST w/ application/xml or POST w/ text/xml (you either need to register both or reg- ister POST w/ * and check the ctype yourself, remember to nerr_raise(CGIParseNotHandled) if you aren't handling the POST). In general, your callback should: Find out how much data is available: l = hdf_get_value (cgi->hdf, "CGI.ContentLength", NULL); len = atoi(l); And read/handle all of the data using cgiwrap_read. See the builtin handlers for how this is done. Note that cgiwrap_read is not guarunteed to return all of the data you request (just like fread(3)) since it might be reading of a socket. Sorry. You should be careful when read- ing the data to watch for short reads (ie, end of file) and cases where the client sends you data ad infinitum. RETURN VALUE
None SEE ALSO
cgi_debug_init(3), cgi_parse(3), cgi_destroy(3), cgi_js_escape(3), cgi_html_escape_strfunc(3), cgi_register_strfuncs(3), cgi_output(3), parse_rfc2388(3), cgi_url_validate(3), open_upload(3), cgi_cs_init(3), cgi_url_escape_more(3), cgi_html_strip_strfunc(3), cgi_neo_error(3), cgi_redirect(3), cgi_filehandle(3), cgi_register_parse_cb(3), cgi_url_escape(3), cgi_init(3), cgi_redirect_uri(3), cgi_cookie_clear(3), cgi_url_unescape(3), cgi_vredirect(3), cgi_display(3), cgi_html_ws_strip(3), cgi_error(3), cgi_cookie_set(3), cgi_text_html_strfunc(3), cgi_cookie_authority ClearSilver 12 July 2007 cgi_register_parse_cb(3)
Check Out this Related Man Page
HTTP::Request::Common(3) User Contributed Perl Documentation HTTP::Request::Common(3) NAME
HTTP::Request::Common - Construct common HTTP::Request objects SYNOPSIS
use HTTP::Request::Common; $ua = LWP::UserAgent->new; $ua->request(GET 'http://www.sn.no/'); $ua->request(POST 'http://somewhere/foo', [foo => bar, bar => foo]); DESCRIPTION
This module provide functions that return newly created "HTTP::Request" objects. These functions are usually more convenient to use than the standard "HTTP::Request" constructor for the most common requests. The following functions are provided: GET $url GET $url, Header => Value,... The GET() function returns an "HTTP::Request" object initialized with the "GET" method and the specified URL. It is roughly equivalent to the following call HTTP::Request->new( GET => $url, HTTP::Headers->new(Header => Value,...), ) but is less cluttered. What is different is that a header named "Content" will initialize the content part of the request instead of setting a header field. Note that GET requests should normally not have a content, so this hack makes more sense for the PUT() and POST() functions described below. The get(...) method of "LWP::UserAgent" exists as a shortcut for $ua->request(GET ...). HEAD $url HEAD $url, Header => Value,... Like GET() but the method in the request is "HEAD". The head(...) method of "LWP::UserAgent" exists as a shortcut for $ua->request(HEAD ...). PUT $url PUT $url, Header => Value,... PUT $url, Header => Value,..., Content => $content Like GET() but the method in the request is "PUT". The content of the request can be specified using the "Content" pseudo-header. This steals a bit of the header field namespace as there is no way to directly specify a header that is actually called "Content". If you really need this you must update the request returned in a separate statement. DELETE $url DELETE $url, Header => Value,... Like GET() but the method in the request is "DELETE". This function is not exported by default. POST $url POST $url, Header => Value,... POST $url, $form_ref, Header => Value,... POST $url, Header => Value,..., Content => $form_ref POST $url, Header => Value,..., Content => $content This works mostly like PUT() with "POST" as the method, but this function also takes a second optional array or hash reference parameter $form_ref. As for PUT() the content can also be specified directly using the "Content" pseudo-header, and you may also provide the $form_ref this way. The $form_ref argument can be used to pass key/value pairs for the form content. By default we will initialize a request using the "application/x-www-form-urlencoded" content type. This means that you can emulate an HTML <form> POSTing like this: POST 'http://www.perl.org/survey.cgi', [ name => 'Gisle Aas', email => 'gisle@aas.no', gender => 'M', born => '1964', perc => '3%', ]; This will create an HTTP::Request object that looks like this: POST http://www.perl.org/survey.cgi Content-Length: 66 Content-Type: application/x-www-form-urlencoded name=Gisle%20Aas&email=gisle%40aas.no&gender=M&born=1964&perc=3%25 Multivalued form fields can be specified by either repeating the field name or by passing the value as an array reference. The POST method also supports the "multipart/form-data" content used for Form-based File Upload as specified in RFC 1867. You trigger this content format by specifying a content type of 'form-data' as one of the request headers. If one of the values in the $form_ref is an array reference, then it is treated as a file part specification with the following interpretation: [ $file, $filename, Header => Value... ] [ undef, $filename, Header => Value,..., Content => $content ] The first value in the array ($file) is the name of a file to open. This file will be read and its content placed in the request. The routine will croak if the file can't be opened. Use an "undef" as $file value if you want to specify the content directly with a "Content" header. The $filename is the filename to report in the request. If this value is undefined, then the basename of the $file will be used. You can specify an empty string as $filename if you want to suppress sending the filename when you provide a $file value. If a $file is provided by no "Content-Type" header, then "Content-Type" and "Content-Encoding" will be filled in automatically with the values returned by LWP::MediaTypes::guess_media_type() Sending my ~/.profile to the survey used as example above can be achieved by this: POST 'http://www.perl.org/survey.cgi', Content_Type => 'form-data', Content => [ name => 'Gisle Aas', email => 'gisle@aas.no', gender => 'M', born => '1964', init => ["$ENV{HOME}/.profile"], ] This will create an HTTP::Request object that almost looks this (the boundary and the content of your ~/.profile is likely to be different): POST http://www.perl.org/survey.cgi Content-Length: 388 Content-Type: multipart/form-data; boundary="6G+f" --6G+f Content-Disposition: form-data; name="name" Gisle Aas --6G+f Content-Disposition: form-data; name="email" gisle@aas.no --6G+f Content-Disposition: form-data; name="gender" M --6G+f Content-Disposition: form-data; name="born" 1964 --6G+f Content-Disposition: form-data; name="init"; filename=".profile" Content-Type: text/plain PATH=/local/perl/bin:$PATH export PATH --6G+f-- If you set the $DYNAMIC_FILE_UPLOAD variable (exportable) to some TRUE value, then you get back a request object with a subroutine closure as the content attribute. This subroutine will read the content of any files on demand and return it in suitable chunks. This allow you to upload arbitrary big files without using lots of memory. You can even upload infinite files like /dev/audio if you wish; however, if the file is not a plain file, there will be no Content-Length header defined for the request. Not all servers (or server applications) like this. Also, if the file(s) change in size between the time the Content-Length is calculated and the time that the last chunk is delivered, the subroutine will "Croak". The post(...) method of "LWP::UserAgent" exists as a shortcut for $ua->request(POST ...). SEE ALSO
HTTP::Request, LWP::UserAgent COPYRIGHT
Copyright 1997-2004, Gisle Aas This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.18.2 2012-09-30 HTTP::Request::Common(3)