[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Body skipped for non-GET (was: Segmentation fault with cu
Re: [Bug-wget] Body skipped for non-GET (was: Segmentation fault with current development version of wget)
Sat, 22 Jun 2013 01:39:03 +0530
Glad the --method command is coming in use.
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
> In case this is really somewhere in the standards, can you provide the
> exact location?
I will have to comb through them again to see what I can find. Though as
far as I remember, there is nothing in the standards that deals with this
> 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.
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.