[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
From: |
Darshit Shah |
Subject: |
Re: [Bug-wget] Body skipped for non-GET (was: Segmentation fault with current development version of wget) |
Date: |
Sat, 22 Jun 2013 01:39:03 +0530 |
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.
> 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
exact situation.
>
> 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.
--
Thanking You,
Darshit Shah