On 21/06/13 22:09, Darshit Shah wrote:
Hi Angel,
Glad the --method command is coming in use.
Replying inline.
However, I discovered that the http reply was not being printed
(only in --debug, with "Skipping %d bytes of body: ...").
I ended up commenting the below extract of the patch.
Why is the body ignored if it's not a GET? This seems wrong. Other
methods like POST or PUT *do* return a body. We are also likely to
be interested in the body for other methods unkown to wget (eg.
PROPFIND). And if it's not desired, ignoring wget output is way
easier than recovering it when it's not provided.
Perhaps the intention was to have strcasecmp(opt.method,"HEAD")==0
instead (but the changelog matches the code).
Yes, I intentionally skipped printing the body for non-GET methods.
The reason was that the data is still being printed in DEBUG output
and I thought it better if we do not clutter the verbose output. Maybe
I was wrong in that?
My reasoning behind it was that, I read that in reply to POST/PUT
commands the server usually only returns the location of the new
resource in the Location Header which we do not print in Verbose
output in any case. I wasn't aware of PROPFIND or that the message
body included may have a lot of uses.
Well, if it returns a redirect, i'm obviously fine with not returning
anything :)
My point is that there are cases where the pages return useful contents,
such as the desired values or error messages.
I just made a silly game at http://www.ángel.net/wget/guessnumber.php It
tells you if you found the number or not, but it could be something more
complex, like a user login.
You could play with a command line like:
wget http://www.ángel.net/wget/guessnumber.php --post-data=number=2
that is, if you're not using master :)
wget 1.14 downloads the posted page, so it's a behavior change.
Not does it only act differently, but on master it will start looping
for --tries due to "Connection closed at byte 0. Retrying." which is no
more than wget itself skipping the full body, then retrying because
there's no body left.
The above thread talks just about redirects, but in this case
there was no redirect involved (just a PUT which
returned a 200 with a small body). So I'm afraid that fixing the
redirects broke non-redirect case. And yes, we
need more tests.
I don't believe that it broke the case, since the current behaviour is
expected. If it is non-optimal, we can always make a change to it. I
will soon reply with a patch that allows saving the response body.
Hmm. Right. It does what you intended, even if I considered that a bug.
We need to decide which is the right thing to do, then.
The lack of tests was a severe constraint in developing this.
Especially since I found it difficult to configure the Server to work
the way I need it. With the new Python based server, it is
considerably easier to perform these tasks. I will add more rigorous
tests for these.
Is it worth trying to get a test case in the perl ones or should we just
wait for the python tests?
Regards