> > I had to turn purging off, and have tried this 
> with 'accept
> > cookies' on and off (above example). What happens is 
that
> > instead of writing a cookie with the value JSESSIONID=
> > httrack creates an HTML file as the index of the 
mirrored
> > site after receiving a warning that the index has moved:
> > 4:21:31 Warning:  File has moved from
> > XX.XXX.XXX.XXX/servlets/sfs?> 
i=1061415216624&b=1061415216624&t=/Default/gateway&include=g
> ateway
> > to
> 
<http://XX.XXX.XXX.XXX/servlets/sfs;jsessionid=BDDA746E422AC1>
> DDD603AD4248DA47B8?> 
s=cpB9D4dbt3HynAUG1&i=1061415216624&b=1061415216624&t=/Defau
> lt/gateway&include=gateway
> 
> Humm, the server seems to be using the parameter zone 
after 
> the path segment (the ; thing) to send a cookie.. weird 
> (standard?)
Not a weird standard. I think both mechanisms are stated in 
the servlet (1.3?) spec.
Tomcat uses both: in the first response for a session it 
sets a cookie AND does url rewriting (the jsession path 
parameter).
In a subsequent request tomcat checks if a cookie is 
present. If present, that is used as the session 
identifier, if this session is still valid inside tomcat 
(not expired), tomcat will not set the cookie again NOR 
will it try url-rewriting again.
The fact that jsessionid is part of the url BEFORE the 
querystring makes it appear in the filename httrack 
generates. (At least I assume this is the reason, Xavier?)
If you open this file, you will see it is not a cookie 
file, but a normal html file.
> 
> > What am i doing wrong?Nothing.
> 
> Well, the cookie is apparently NOT send through the usual 
> way (a set-cookie header in the http headers) bu using a 
> redirected URL ; which is a bit weird
> 
> You may try to check the server cookie confuguration?> 
It is not weird, it is one of the mechanisms described in 
the servlet spec.
If you are interested, read: 
<http://www.jcp.org/aboutJava/communityprocess/first/jsr053/s>
ervlet23_PFD.pdf
Check out section 7.1 on Session Tracking Mechanisms.