DACSHTTP(1)                  DACS Commands Manual                  DACSHTTP(1)

       dacshttp - perform an HTTP/HTTPS request

       dacshttp [-get | -post | -delete | -head | -options | -soptions | -put]
                [-ll log_level]
                [-prompt] [-v] [--version] [[-ct string] |
                [--content-type string]]
                [{-header name value}...] [-headers filename] [-body filename]
                [-user-agent string] [{-p name value}...] [-proto version-num]
                [-proxy proxyhost:proxyport]
                [-proxymatch hostname[:port] proxyhost:proxyport]
                [-f name filename] [{-cookies filename}...] [-ah]
                [-ssl command-line] [-ssl-flags flags] uri

       This program is part of the DACS suite. It is a stand-alone program
       that neither accepts the usual DACS command line options
       (dacsoptions[1]) nor accesses any DACS configuration files.

       This general-purpose utility sends an HTTP/HTTPS request for uri to a
       web server and prints the reply to its standard output.

       dacshttp will automatically follow redirects according to RFC 2616[2]
       and up to a compile-time maximum, unless the -prompt flag is given. A
       non-standard extension is that a redirect to a non-absolute URI is
       interpreted in a manner compatible with most browsers.

       In versions 1.4.27b and earlier, this command was called http.

           DACS can issue its own HTTP requests, such as from
           dacs_authenticate to an external authentication module. This HTTP
           functionality is provided by the same support code that the
           dacshttp command uses, and therefore much of the following
           information applies to these internally generated requests also
           (e.g., HTTP_PROG[3], SSL_PROG[4], SSL_PROG_ARGS[5],
           SSL_PROG_CA_CRT[6], SSL_PROG_CLIENT_CRT[7], VFS[8]).

       The HTTP GET method is used by default, but some flags implicitly
       select a different method (e.g., -f and -p). One of the following flags
       can be used to explicitly specify the HTTP method, provided it is
       compatible with the other options:

           Use the GET method (the default).

           Use the POST method.

           Use the HEAD method.

           Use the PUT method.

           Use the DELETE method.

           Use the OPTIONS method.

           Use the OPTIONS method but ignore anything that follows the
           authority component of uri and instead use the special case "*"
           request URI that means that the request applies to the server
           itself rather than to a particular resource.

       These command line flags are also recognized:

           If cookies (credentials) are to be sent (see -cookies), use an
           Authorization header rather than a Cookie header.

       -body filename
           Read the message body from filename. It is assumed that the body
           has already been appropriately formatted for the request's content

       -cookies filename
           Obtain cookies from filename, one per line, to send with the
           request using the Cookie header. Multiple cookies are separated
           using a semi-colon, which follows the Netscape spec[9].
           Alternatively, multiple cookies can be combined on a single line,
           separated by either a semi-colon or a comma (following RFC 2109[10]
           or RFC 2965[11]). This argument may be repeated.

       -ct string
       --content-type string
           Set the Content-Type request-header to string. If the request has
           an entity-body, the default Content-Type is
           application/x-www-form-urlencoded; if the request does not have an
           entity-body, by default the Content-Type request-header is not set.

       -f name filename
           Passes and encodes the contents of filename as the value for name.
           By default, the POST method will be used, although PUT and OPTIONS
           can be selected. If filename is "-", the standard input is read;
           this form can only be used once on the command line. This argument
           may be repeated.

       -header name value
           This flag, which may be repeated, causes the HTTP header name:
           value to be sent with the request. Neither name nor value are
           checked in any way.

               This will not override headers required or implied by other
               command line flags; for example, the following flags are not

                   -header User-Agent foo
                   -user-agent foo

               The former case will send the User-Agent header twice.

       -headers filename
           Read additional message headers from filename, one per line, and
           send them with the request (refer to the -header flag). This flag
           may be repeated.

           Include the HTTP response headers in the output. They are
           terminated by a blank line. The status line is labelled

       -ll log_level
           Set the debugging output level to log_level (see dacs(1)[12]). The
           default level is warn, and the -v flag bumps the level to debug or

       -p name value
           Passes and encodes name=value as part of the entity-body. By
           default, the POST method will be used, although PUT and OPTIONS can
           be selected. This argument may be repeated.

           Prompt the user for permission to proceed after certain events,
           such as receiving a redirect; the response is affirmative only if
           it is "yes" or "y". If this option is not specified, the
           affirmative action will automatically be taken.

       -proto version-num
           Function in compliance with version-num of the HTTP protocol (e.g.,

       -proxy proxyhost:proxyport
           Forward all HTTP requests (except for those that match a
           -proxymatch flag) to the proxy server at proxyport (a numeric port
           number or recognized service name) on proxyhost (a domain name or
           IP address). Proxying is not fully supported by dacshttp, but it
           will connect to the specified proxy server instead of the server
           implied by uri.

       -proxymatch hostname[:port] proxyhost:proxyport
           If hostname matches the host specified in uri, proxy the HTTP
           request through proxyhost (a domain name or IP address) at
           proxyport (a numeric port number or recognized service name). If
           port is not given, it is assumed to be 80 (for the http scheme) or
           443 (for the https scheme). Matching is done by resolving hostname
           to an IP address (if necessary) and comparing it to the effective
           IP address that is specified by uri. This flag is given priority
           over the -proxy flag, so it can be used to override a default proxy

               This option is not implemented. The SSL flags apply to all
               connections; this is probably a bug.

       -ssl command-line
           This flag indicates that HTTPS (i.e, HTTP over an SSL connection)
           is to be used, regardless of the scheme specified by uri. Because
           dacshttp does not directly include SSL functionality, it uses pipes
           to communicate with an external program that provides the SSL
           connection. The sslclient(1)[13] command is strongly recommended
           for this purpose (version 3.26 of stunnel(1) and stunnel3, which
           comes with some releases of stunnel-4.x, might also work).

           The command-line is a complete shell command line that will be used
           to run the program as a filter. For example, this argument might
           look like either of:

               -ssl "/usr/local/dacs/bin/sslclient example.com:443"

               -ssl "/usr/local/bin/stunnel -c -r example.com:443"

           If the -ssl argument is absent but the uri argument uses the https
           scheme, dacshttp will still try to use SSL. It will attempt to use
           sslclient(1)[13] and assume it is in its default location. If the
           -ssl argument is present but specifies only one string, that string
           is assumed to be the path to sslclient(1)[13]. The first example
           below will run sslclient(1)[13] from /tmp/sslclient to connect to
           port 443 at example.com; the second example has the same effect but
           will run sslclient(1)[13] from its default location:

               % dacshttp -ssl "/tmp/sslclient" https://example.com
               % dacshttp https://example.com

       -ssl-flags flags
           If SSL operation is enabled but the -ssl flag is absent or did not
           simply specify a pathname, append flags to the list of arguments to
           be passed to the external SSL provider; when the -ssl flag
           specifies more than one argument, this flag is ignored. The flags
           string is a space-separated list of arguments. This flag may be

           For example, in this example dacshttp will invoke sslclient with
           the two arguments -sm and bobo.example.com:

               % dacshttp -ssl-flags "-sm bobo.example.com" https://example.com

           If a wildcard server certificate is used, it may be necessary to
           explicitly match all hosts within a specific domain:

               % dacshttp -ssl-flags "-sm .*\.example\.com" https://example.com

               When called by dacshttp, error messages produced by sslclient
               may be lost. If you encounter problems with SSL operation, work
               with sslclient(1)[13] to ensure that an SSL connection can be
               established, or to determine and resolve the problem. If you
               discover that sslclient requires command line flags for proper
               operation, you will need to make sure that dacshttp passes
               those flags to it.

       -user-agent string
           Set the User-Agent request-header to string. If not provided, this
           string will have the prefix "DACS-http/", followed by a DACS
           release identifier (example: "DACS-http/1.4.1").

           Increase the level of debugging output. This will cause response
           headers to be displayed, for example. The flag may be repeated.

           Print version information to stderr, then exit immediately.

       The uri argument is the URL to invoke. It may include a query string
       suffix (even if HTTP POST is selected).

       Whether selected implicitly or explicitly, the command line must
       specify exactly one of the HTTP methods.

       Request headers specified using the -header or -headers flags are sent
       in the order in which the flags appear on the command line. If they are
       read from a file, there ordering is maintained.

       The following will retrieve RFC 2616[2] and save it in rfc2616.txt:

           % dacshttp "http://www.rfc-editor.org/rfc/rfc2616.txt" > rfc2616.txt

       This will do a GET on the given URL, passing the query string foo=baz,
       and writing the result to stdout:

           % dacshttp "https://example.com/cgi-bin/dacs/dacs_prenv?foo=baz"

       This will do a POST on the given URL, passing two arguments:

           % dacshttp -p foo baz -p bar zork https://example.com/cgi-bin/dacs/dacs_prenv

       This will make an HTTP GET method request over SSL to the given URL:

           % dacshttp -ssl "/usr/local/dacs/bin/sslclient example.com:443" \

       The program exits 0 if everything was fine, 1 if an error occurred.

       Use of an SSL provider other than sslclient(1)[13] is officially
       deprecated. Recent development makes it doubtful that any other program
       will function properly with dacshttp.

       It is only a partial implementation of RFC 2616[2] (HTTP 1.0). It only
       talks HTTP (no other URI schemes are supported). Received cookies are
       discarded, there is no support for RFC 2617[14] authentication,
       including proxy authentication, and no client-side caching is
       performed.  dacshttp should not require an external program to provide
       SSL functionality. The program is a bit confused about when it should
       be able to send a message body.

       sslclient(1)[13], lynx(1)[15], curl(1)[16], Wget(1)[17], RFC 1738[18],
       RFC 2396[19], RFC 2616[2], RFC 3986[20]

       Distributed Systems Software (www.dss.ca[21])

       Copyright2003-2013 Distributed Systems Software. See the LICENSE[22]
       file that accompanies the distribution for licensing information.

        1. dacsoptions

        2. RFC 2616

        3. HTTP_PROG

        4. SSL_PROG

        5. SSL_PROG_ARGS

        6. SSL_PROG_CA_CRT


        8. VFS

        9. Netscape spec

       10. RFC 2109

       11. RFC 2965

       12. dacs(1)

       13. sslclient(1)

       14. RFC 2617

       15. lynx(1)

       16. curl(1)

       17. Wget(1)

       18. RFC 1738

       19. RFC 2396

       20. RFC 3986

       21. www.dss.ca

       22. LICENSE

DACS 1.4.28b                      02/04/2014                       DACSHTTP(1)