Man Pages

HTTP::Request::Common(3) - phpMan HTTP::Request::Common(3) - phpMan

Command: man perldoc info search(apropos)  

HTTP::Request::Common(User Contributed Perl DocumentatHTTP::Request::Common(3)

       HTTP::Request::Common - Construct common HTTP::Request objects

         use HTTP::Request::Common;
         $ua = LWP::UserAgent->new;
         $ua->request(GET '');
         $ua->request(POST 'http://somewhere/foo', [foo => bar, bar => foo]);

       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 follow-
       ing 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

                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 con-
           tent, 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 funciton 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 ini-
           tialize a request using the "application/x-www-form-urlencoded" content type.  This means that you can emu-
           late a HTML <form> POSTing like this:

             POST '',
                  [ name   => 'Gisle Aas',
                    email  => '',
                    gender => 'M',
                    born   => '1964',
                    perc   => '3%',

           This will create a HTTP::Request object that looks like this:

             Content-Length: 66
             Content-Type: application/x-www-form-urlencoded


           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 speci-
           fied 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

           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 '',
                  Content_Type => 'form-data',
                  Content      => [ name  => 'Gisle Aas',
                                    email => '',
                                    gender => 'M',
                                    born   => '1964',
                                    init   => ["$ENV{HOME}/.profile"],

           This will create a HTTP::Request object that almost looks this (the boundary and the content of your
           ~/.profile is likely to be different):

             Content-Length: 388
             Content-Type: multipart/form-data; boundary="6G+f"

             Content-Disposition: form-data; name="name"

             Gisle Aas
             Content-Disposition: form-data; name="email"

             Content-Disposition: form-data; name="gender"

             Content-Disposition: form-data; name="born"

             Content-Disposition: form-data; name="init"; filename=".profile"
             Content-Type: text/plain

             export PATH


           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 ...).

       HTTP::Request, LWP::UserAgent

       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.8.8                       2008-12-05          HTTP::Request::Common(3)