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.

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

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

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. Alternatively, multiple cookies can be combined on a single line, separated by either a semi-colon or a comma (following RFC 2109 or RFC 2965). This argument may be repeated.

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.

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.

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.

-header User-Agent foo
-user-agent foo

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 "Status-Line".

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

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.

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

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.

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

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) 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) 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). The first example below will run sslclient(1) from /tmp/sslclient to connect to port 443 at example.com; the second example has the same effect but will run sslclient(1) from its default location:

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

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

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

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.