SYNOPSIS<header NAME=$name [VALUE=$value] [options]>
or
<header COOKIE=$name [VALUE=$value] [options] [cookie-options]>
DESCRIPTION
The header function prints an HTTP header. Normally Vortex
takes care of printing headers, such as Content-Type, before
the script begins, so that all of the script's output is part of the
body. However, in some circumstances it is desirable for a script to
print additional headers, override default Vortex headers, or change
headers at run-time. In such cases the header function can be
used.
It is important to note that since headers are only valid before the
body/content of the output, the header function, if used,
should be called before any content is generated. Otherwise
the output of header may be suppressed, lose its effect, and/or
be visible to the user (see the PRINTIF option for more info).
If the NAME option is given, a generic header will be
printed. Its value will be VALUE. This form can be used to
print a Location header to redirect the user, for example.
If the COOKIE option is given, a Set-Cookie header
will be printed
. The name of the cookie will be $name,
and its value will be $value, URL-encoded so that non-ASCII
characters are safe. This provides a way to export "permanent" or
"session" data in Vortex, since HTTP cookies are automatically
URL-decoded and imported into variables (of the same name as the
cookie) on future script invocations. It also provides a cross-script
method of exporting data, since cookies are not inherently part of the
URL.
Options valid for named headers as well as COOKIEs:
PRINTIF=$flags
Only print header if conditions specified by zero or more
space-separated values in $flags are met. If $flags
is empty or unset, the value of
[Texis] Default Header Printif
(here) from texis.ini is
used. If that is unset, the value headers is used. A
protocol and a content condition are tested; both conditions must
be true for the header (or Secure flag) to be printed:
http (protocol)
True if running under CGI with HTTPhttps (protocol)
True if running under CGI with HTTPscmdline (protocol)
True if running from command lineheaders (content)
True if CGI and still printing headerscontent (content)
True if command line, or CGI and past headersalways (protocol and content)
Always true
Several additional options are valid for COOKIEs only:
DOMAIN=domain
Specifies a domain to restrict the cookie to. Normally a browser
will return the cookie only to the single host it was received
from. To make the browser return it to all hosts in a given
domain, e.g. x.com, set DOMAIN to ".x.com.
(Note: see RFC 2109 for more on the syntax of DOMAIN.)
Added in version 3.0.957500000 20000504.MAX-AGE=seconds
Specifies a maximum age for the cookie, in seconds. After the
given number of seconds, the user's browser is to discard
the cookie, no longer returning it in future requests. A
MAX-AGE of 0 means to discard the cookie immediately. If
no MAX-AGE or EXPIRES time is given, the cookie is a
session cookie, and will be discarded when the browser is closed.EXPIRES=time
An alternate method of specifying the maximum age of the cookie.
The time is a Texis-parseable date/time, such as "+1 week".PATH=path
Gives the valid root path for the cookie. This is the subset of
URLs for which the cookie is to be returned by the browser. If
not specified it defaults to /, which means that all URLs
for the host will be returned the cookie. A longer path could be
given to restrict the cookie to a smaller URL tree.SECUREIF=$flags
If given, and conditions specified by $flags are met, print
Secure flag with cookie, which instructs browsers to only
return the cookie over a secure (e.g. HTTPs) connection. Syntax
and defaults are the same as for PRINTIF, except that there
is no texis.ini value checked as a fallback, and the
additional condition exists that the SECUREIF option must
also be given explicitly for Secure to be printed (in
addition to protocol and content conditions). Note also that the
content condition default changed in version 7.07.1619560502
20210427 (see footnote under PRINTIF).
HTTPONLY
Set HttpOnly flag in header. If the browser/user-agent
supports it, this flag will prevent access or modification of the
cookie by client-side scripts, which may help prevent
cross-site-scripting (XSS) attacks by malicious scripts. If the
browser does not support the flag, it will typically be ignored.
Added in version 5.01.1244880000 20090613.
Use of the header function is preferred over the old method
of setting the URL extension to .bin, since it is more
flexible. The script can print some, all, or none of its headers,
even override Vortex headers such as Content-Type.
DIAGNOSTICSheader returns nothing.
EXAMPLE<a name=look>
<if $MagicCookie != "MagicValue">
<header name="Location"
value="http://www.example.com/login.html">
Your login is incorrect.
Please <a href="/login.html">login</a>.
<exit>
</if>
<!-- Proceed with top of HTML: -->
<body>
<h2>My Site</h2>
</a>
This function checks the user's (previous) login cookie: if it is incorrect, they are redirected to a login page. This function could be called at the top of any start function to verify the user.
CAVEATS
The header function was added in version 2.6.913000000 19981207. It must be called before any body output is
printed for the header to be interpreted properly.
The header function controls headers printed by Vortex in
CGI output. It does not control headers sent to other servers
via <fetch>; see <urlcp header> (here)
instead.
Web servers may insert, modify, or delete headers printed by CGI
programs such as Vortex, including those printed with header.
This behavior is beyond Vortex's control. In some cases it is
necessary, as with the Location header: the server must parse
it to change the HTTP response code to 302, because the HTTP response
is printed before the Location header.
The header function does not yet work properly in conjunction
with the .bin URL extension syntax.
Printing a Content-Type header may affect the default
HTML-encoding of output variables, if the type is changed to/from
text/html. If a Content-Type header is not printed, one
will be added to the headers as usual.
The returning of cookies on future requests, to the proper URLs, and
their disposal at the MAX-AGE time is entirely up to the user's
browser. If the user deletes their cookie cache, the browser does not
or cannot accept cookies, or has a faulty implementation, cookies may
not be returned as expected.
Although COOKIE values are automatically URL-encoded and
decoded, they are sent as plain-ASCII values, so type information
is lost. Upon receipt, cookies have the same type as if they were
form variables: string or integer.
SEE ALSO
URL syntax, EXPORT, RFC 2109 (cookie specification)