[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ángel González
Subject: Re: [Bug-wget] Body skipped for non-GET
Date: Fri, 21 Jun 2013 23:29:51 +0200
User-agent: Thunderbird

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]