Mario Ander schrieb:
Hi everybody,
I think there is a bug storing cookies with wget.
See this command line:
C:\Programme\wget\wget --user-agent=Opera/8.5 (X11;
U; en) --no-check-certificate --keep-session-cookies
--save-cookies=cookie.txt --output-document=-
--debug --output-file
Matthias Vill schrieb:
Mario Ander schrieb:
Hi everybody,
I think there is a bug storing cookies with wget.
See this command line:
C:\Programme\wget\wget --user-agent=Opera/8.5 (X11;
U; en) --no-check-certificate --keep-session-cookies
--save-cookies=cookie.txt --output-document
Hi everybody,
I think there is a bug storing cookies with wget.
See this command line:
C:\Programme\wget\wget --user-agent=Opera/8.5 (X11;
U; en) --no-check-certificate --keep-session-cookies
--save-cookies=cookie.txt --output-document=-
--debug --output-file=debug.txt
--post-data=name
Rüdiger Cordes [EMAIL PROTECTED] writes:
there is no description how to turn on cookie storing nor how to use
the command line to tell wget to use two cookies.
Do you have access to the info manual? It does describe the options
`--load-cookies' and `--save-cookies', which are relevant for
Hello,
there is no description how to turn on cookie storing nor how to use
the command line
to tell wget to use two cookies.
For me under MacOSX 10.3.4 one cookie is functioning with
--header Cookie: cookie1=A1
But two are not functioning.
Either with
--header Cookie: cookie1=A1 cookie2=B2
nor
, NET, ORG, GOV, MIL, and INT.
The default value of domain is the host name of the server which generated
the cookie response.
It appears that the algorithm for cookie matching in
wget-1.8.1/src/cookies.c does not agree with this spec.
Jeff
Log trace:
$ wget -d --load-cookies c:/temp
Just a couple of note with cookies if someone hasn't already pointed
them out
When using a proxy server, there will be a mismatch in
check_domain_match() and fail on debug step 4
Because the u-host will equal the proxy server if used whilst comparing
against cookie-domain name (ie using
On Fri, 2 Nov 2001, Matt wrote:
[bug cut out, sounds like a true bug and a decent fix]
the parsing of the cookie domain name will fail on many websites which
have the domain (domainname.com) without the . in front. Places like
altavista.com will fail but correct ones like google.com will
Michael Klaus wrote:
Dear WGet team,
first of all, i want to say that WGet really is a _great_ program. My
company is mostly using it for regression tests for different web
servers and servlet engines. And there's the problem. Servlet engines
meintain their sessions - which are critical
