Webmirror 2.0
cookie no
cookie yes
cookie 3dots
cookie dots
cookie nodots
cookie domain
cookie nodomain
cookie save session
cookie dont save session
cookie backup nn
cookie file file_name
cookie load file_name
Cookie handling is quite complex. If you do not worry about cookies, and you should not
too much, IMHO then you can use the default settings. By default cookie handling is switched
on.
yes, no
You can switch it off saying cookie no or cookies no. (You can always use cookies
instead of cookie.)
xdots
Cookies can define the domain where to send them back. When you download a page from www.mydom.com
accompanied with a cookie the cookie should tell you what domain it is supposed to sent back. This
domain is like mydom.com that says the cookie should be sent to www.mydom.com as well as
w3.mydom.com or to anyserver.maydom.com
The default value is to send the cookie back to the machine where it came from.
Cookie specification requires that there should be at least two dots in the domain if specified. However
this way you would not allow http://cnn.com to send you a cookie with a domain cnn.com.
Therefore the default value is to request at least one dot in the cookie domain. If a cookie
specifies a domain with less dots than requested the cookie is abandoned.
3dots says that you stritly request at least three dots as in the specification.
dots says that you request at least two dots. This is the default.
nodots says that you do not care about dots. (I do not recomment to use this setting, but you are free
to use.)
domain
The cookie domain should match the server that send it to you. In other words the server should
be in the cookie domain that is sends. For example cnn.com will never send you a cookie
(hopefully) that contains a domain .nbc.com. It is very dangerous and usually a
clear sign of crack (or server programmer error) when a server send you a cookie with a
domain that does not fit the server.
The mirroring process checks the cookie domains against the sending server and abandones cookies that
contain domain specification not matching the sending server. However you can purposfully switch off
this check saying cookie nodomain. You can switch on the domain checking with cookie domain
in case the checking was switched off in an earlier line in the retrieval definiton file (perhaps
in an included file).
file file_name
Cookies can be saved between download processes. This command tells the mirror program which file
to use as cookie file. When the process starts it loads the cookies from the file and when the process
ends it saves the cookies into this file. This way the program can use the cookies still valid sent to it
in previous mirror processes.
The file the cookies are stored are text format, human readable file so long as long you can read
cookie information.
load file_name
Cookies can be loaded using this command from different cookie files using this command. The cookies
loaded and used from the specified files and are merged with the cookies loaded from other files.
save session
Cookies usually contain an expiration time. This can be rather far away, like December 31, 2020. Other
cookies do not contain expiration time. These are so called session cookies and are supposed to be
valid until the user exits the browser. This command in the retrieval definiton file says that the
program should save these cookies as well together with the cookies having expiration time specified.
backup nn
You can define how many old backup files the program should keep when saving a cookie file.
TOC