Re: [Bug-wget] Body skipped for non-GET

[Ángel González]

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