The obvious problem is that this command lacks --keep-session-cookies,
and the cookie it gets is session-based.
I tried to reproduce the bug in the more generic way.
But there are other problems
as well: if you examine the cookie.txt produced by (the amended
version of) the first command, you'll no
[EMAIL PROTECTED] writes:
>> Is there a publically accessible site that exhibits this problem?
>
> I've set up a small example which illustrates the problem. Files can
> be found at http://dev.mesca.net/wget/ (using demo:test as login).
Thanks for setting up this test case. It has uncovered at l
Is there a publically accessible site that exhibits this problem?
I've set up a small example which illustrates the problem. Files can be
found at http://dev.mesca.net/wget/ (using demo:test as login).
Three files:
setcookie.php:
--
getcookie.php:
--
get-cookie-redirect.
[EMAIL PROTECTED] writes:
> - The server responds with a "Location: http://host.com/member.php"; in
> headers. Here is the point : member.php requires cookies defined by
> index.php and checkuser.php. However these cookies are not resended by
> Wget.
That sounds like a bug. Wget is supposed to r
Hello,
I use Wget version 1.10-alpha2+cvs-dev (because of the avalability of
the --keep-session-cookies option).
I'm trying to wget a member page, where cookies are required for access.
The usual login procedure is:
-
- Get a session cookie (PHPSESSID) on http://host.c
