The following urlcp settings control how cookies are processed by the fetch functions. The "cookie jar" is Vortex's internal cache of cookies received during fetches and/or directly set by cookiejar. Starting with version 4.01.1022000000 20020521, Vortex automatically receives and sends cookies according to the RFC 2109 pecification, with modifications to mimic popular browsers' behavior. This largely eliminates the need for explicit header setting calls.

  • acceptnewcookies (boolean) Whether to accept new cookies (i.e. first-time-seen). Returns previous setting. Added in version 5.01.1214274000 20080623. On by default.

  • acceptcookiemods (boolean) Whether to accept cookie modifications, i.e. new non-empty non-expired values for cookies already seen. Returns previous setting. Added in version 5.01.1214274000 20080623. On by default.

  • acceptcookiedels aka acceptcookiedeletes (boolean) Whether to accept cookie deletes, i.e. empty or expired values for cookies already seen. Returns previous setting. Added in version 5.01.1214274000 20080623. On by default.

  • acceptcookies (integer) A deprecated alias for acceptnewcookies, acceptcookiemods, acceptcookiedels all together: bit 0 sets acceptnewcookies, bit 2 acceptcookiemods, bit 3 acceptcookiedels. Returns previous value. Note: Previous to version 5.01.1214274000 20080623, this was a boolean setting.

  • cookiedomainmatchself (boolean) Whether a cookie's Domain value should match itself when it has a leading dot, i.e. whether a Domain of "" should domain-match a host of "" and thus be sent to that host. This is technically not permitted by RFC 2965, but is common browser behavior. On by default. Added in version 5.01.1225147420 20081027.

  • cookiejar $cookies [append] Sets the "cookie jar" (internal list of cookies) by processing the text buffer $cookies. The format of the buffer is either Netscape or (in version 4.02.1042149825 20030109 and later) Microsoft Internet Explorer, so a browser cookie file can be directly read and processed to inherit a browser's persistent cookies. The Netscape format is one cookie per line, with the tab-separated values: Domain IsOkAllDomain Path IsSecure IsHttpOnly Expires Name Value. E.g. the line:   TRUE  /  FALSE  FALSE  0  MyCookie  MyValue
    would represent a session cookie named MyCookie with value MyValue sent for any path for any site in the domain Note that the IsHttpOnly column was added in version 5.01.1244880000 20090613, and is not Netscape-format compatible.

    If the second argument is append, the cookie jar is not cleared before processing the buffer (the default is to clear the cookie jar first).

  • cookies (integer or boolean) Controls the acceptnewcookies, sendcookies, acceptcookiemods and acceptcookiedels settings together. If a boolean value is given, all settings are set to that value. If an integer is given, bit 0 applies to the acceptnewcookies, bit 1 to sendcookies, bit 2 to acceptcookiemods and bit 3 to acceptcookiedels. Returns the previous setting (integer). Added in version 4.01.1022000000 20020521. Note: values changed in version 5.01.1214274000 20080623.

  • cookiewildcards (boolean) Controls whether wildcards are acceptable in cookies set with cookiejar (they are never acceptable from cookies seen "in the wild" from hosts). If true, the domain and/or path component of a cookiejar cookie may be a single asterisk ("*") to indicate the cookie matches all hosts and/or all paths, respectively. The default is false, i.e. wildcards are not allowed. Added in version 5.01.1122648771 20050729 (default false in previous versions). Returns previous setting.

    Enabling wildcards can be useful when doing proxy cookie authentication, i.e. passing cookies sent to Vortex along to a <fetch>. The issue is that when cookies are sent back to a server (i.e. to Vortex), the original Set-Cookie header's domain and path are lost, so they cannot be forwarded at the cookiejar call. Thus Vortex does not know the hosts/paths to forward the cookies to (and which not to). Enabling wildcards allows a domain/path of "*" to be set in cookiejar, which will forward the cookies to all hosts and paths, ensuring they reached the needed hosts. (It may also forward them to the wrong hosts, but that is unavoidable and usually benign.) Without wildcards, it is not feasible to set a domain/path syntax that encompasses all possible hosts and paths.

  • metacookies (boolean)

    Whether to accept <meta http-equiv> cookies or not. These are increasingly considered a security issue, because they are easier for malware to set than an HTTP Set-Cookie header. Thus major browsers (as of 2018) are starting not to accept such cookies. The default is on in version 7, off in version 8 and later. Added in version 7.07.1581463000 20200211.

  • sendcookies (boolean) Whether to send cookies (i.e. send the appropriate cookies from the cookie jar). On by default. Returns previous setting. Added in version 4.01.1022000000 20020521.

See also cookiemsgs in the Informational/Trace section (here)

Copyright © Thunderstone Software     Last updated: Oct 24 2023
Copyright © 2024 Thunderstone Software LLC. All rights reserved.