Hi,
I'm not sure wether I'm experiencing a bug or not, so just to let you know.
After a few hours of headache I found out my --post-data option didn't
work as I expected because the data I send has to be URL-escaped. This
is not mentioned both in the manpage and inline help. A remark would
be
Zitat von Micah Cowan [EMAIL PROTECTED]:
Hm, that should not be. It should definitely set the timestamp if it
gets downloaded... I'll investigate.
OOC, was there a specific resource you tested against (just in case I
have difficulty reproducing)?
Not a very specific one, just used our
control H [EMAIL PROTECTED] writes:
After a few hours of headache I found out my --post-data option
didn't work as I expected because the data I send has to be
URL-escaped. This is not mentioned both in the manpage and inline
help. A remark would be helpful.
Note that, in general, it
And now, for a change, a case, that works now (better) ;-)
This is an example where a HEAD request gets a 500 Error response.
Wget default options again, but contentdisposition=yes to force a HEAD.
wget.111-svn-0709 --debug -e contentdisposition = yes
And now, finally, the ultimate real-life test with proxy-cache, timestamping and
contentdisposition, where HEAD and GET have different timestamps.
And this is perfectly correct now !
So it looks now to me, that the new error (local timestamp not set to remote)
only occurs in the cases when
Hi,
though the man page of wget mentions .netrc, I assume this is a bug.
For my understanding if you provide a --user=user and --password=password
at the command line this should overwrite any setting elsewhere, as in
the .netrc. It doesn't. And it took me quite some time and bothering
other
