There we go.
Attaching the next iteration of the patch to add more REStful scripting
options.
Changes included are:
* Accept an option during invocation, called --method=MethodString. The
MethodString will be converted to Uppercase and sent as the Method.
* The old --post-data and --post-file
As expected, explicitly setting opt.method = POST results in a
Segmentation Fault if the server sends a redirect response. This will occur
because, when processing the new url, both opt.method and opt.post-data /
opt.post_file_name are set.
The only sane way of making post-data / post-file ride on
Attaching a patch file for the inclusion of a generic --method command to
send other HTTP Methods through wget.
Changes included are:
* Accept an option during invocation, called --method=MethodString. The
MethodString will be converted to Uppercase and sent as the Method.
* Unlike the case with
Thanks!
I'll incorporate that advice in my code.
Also, I have the documentation ready in a separate branch. Will merge and
submit a final patch.
However, I would really like to remove the redundant code I have created by
testing for body_data || body_file and post_data || post_file separately.
Hi Darshit,
Darshit Shah dar...@gmail.com writes:
I have implemented a --method command along with --body-data and --body-file
commands for HTTP Scripting.
Have attached the patch alongwith this mail. However, this is not complete,
not to my satisfaction atleast.
There is redundant code
I have implemented a --method command along with --body-data and
--body-file commands for HTTP Scripting.
Have attached the patch alongwith this mail. However, this is not complete,
not to my satisfaction atleast.
There is redundant code that executes the old --post-data and --post-file
commands.
please don't add these. I don't think we would like to add a new pair
of --FOO-data, --FOO-file for any method we will implement. As already
suggested by Hrvoje, just add --body-data and --body-file that are
synonyms for --post-data and --post-file; we can't drop these for
backward
Darshit Shah dar...@gmail.com writes:
please don't add these. I don't think we would like to add a new
pair
of --FOO-data, --FOO-file for any method we will implement. As
already
suggested by Hrvoje, just add --body-data and --body-file that are
synonyms for
Darshit Shah dar...@gmail.com writes:
Reusing post-data and post-file is not intuitive enough when we support
more options through --method.
Say, someone wished to use --method=PUT. In that case using --post-data
or --post-file is counter intuitive. Hence the need to unify them
Also, alongwith implementing --body-data and --body-file should I mark the
--post-data and --post-file commands as deprecated? Or is there a different
protocol to follow before marking a command as deprecated?
On Mon, Mar 11, 2013 at 7:38 PM, Darshit Shah dar...@gmail.com wrote:
None.
Fine,
Darshit Shah dar...@gmail.com writes:
Also, alongwith implementing --body-data and --body-file should I mark
the --post-data and --post-file commands as deprecated? Or is there a
different protocol to follow before marking a command as deprecated?
I don't see any real value to mark
Darshit Shah dar...@gmail.com writes:
Okay gathering inputs from all the replies above., I think the best way to
move forward would be to implement a --method=GET|POST|PUT|DELETE
followed by --post-data or --post-file in case of POST and --put-data
--put-file in case of the PUT option.
Since
Hrvoje Niksic wrote:
Another possibility would be to add some more syntax to --method so as to
allow --method=POST:file=foo, and also --method=PUT:data=abc
Since '=' is a valid (and frequent) delimiter for what follows data=
perhaps another pair of delimiters would be better. How about
On 08/03/13 19:18, Darshit Shah wrote:
Okay gathering inputs from all the replies above., I think the best way to
move forward would be to implement a --method=GET|POST|PUT|DELETE
followed by --post-data or --post-file in case of POST and --put-data
--put-file in case of the PUT option.
In
Am Dienstag, 5. März 2013 schrieb Darshit Shah:
Need some help with writing a test for this functionality.
I have implemented a --method=HHTPMethod command that currently supports
DELETE only.
I would be very grateful if someone can help me with writing a test to
ensure that this is working
On 07/03/13 05:37, Steven M. Schweda wrote:
wget --options=POST `cat POSTdata` URL
Why not go with that?
Apparently always means something to you which is different from
what it means to me.
It may be hard to believe, or you may not care, but some folks use
this program on
Am Thursday 07 March 2013 schrieb Darshit Shah:
Okay, these are certain points that do not come instantly to me.
However, I never intended to break these. The above functionality would
remain for backward compatibility with old scripts.
I am simply debating on how to implement this as a new
Tim Ruehsen tim.rueh...@gmx.de writes:
BTW:
How can Wget create a POST without any data (without Content-Type and Content-
Length) ? Curl can...
If by without any data you mean with empty POST data, use
`--post-data='. But that will send 0 Content-Length and the usual
Content-Type. As
Taking this forward. I figured it would be best to merge --post-data and
--post-file commands into --method=HTTPMethod
I intend to use the following logic in merging them:
wget --method=POST [data/file] URL
The text immediately following --method=POST is first assumed to be data.
If however it
On Wed, 6 Mar 2013, Darshit Shah wrote:
I intend to use the following logic in merging them:
wget --method=POST [data/file] URL
The text immediately following --method=POST is first assumed to be data. If
however it does not exist in the key:value format, assume that to be a file
path and
On Thu, 7 Mar 2013, Darshit Shah wrote:
The only reason I said that is, even currently wget only accepts post data
in a key=value format.*
Oh wow.
I guess it proves I never use this feature with wget - no big surprise there
probably. But I consider that to be a terrible limitation as well,
The only reason I said that is, even currently wget only accepts post data
in a key=value format.*
*sorry it's not key:value but key=value.
On Mar 7, 2013 12:12 AM, Daniel Stenberg dan...@haxx.se wrote:
On Wed, 6 Mar 2013, Darshit Shah wrote:
I intend to use the following logic in merging
Darshit Shah dar...@gmail.com writes:
Taking this forward. I figured it would be best to merge --post-data and
--post-file commands into --method=HTTPMethod
I intend to use the following logic in merging them:
wget --method=POST [data/file] URL
If a method (like OPTIONS) includes an
Daniel Stenberg dan...@haxx.se writes:
On Thu, 7 Mar 2013, Darshit Shah wrote:
The only reason I said that is, even currently wget only accepts
post data in a key=value format.*
Oh wow.
The above claim is patently false. Wget doesn't care about the format
of --post-data or the contents of
Okay, I just checked. The man page clearly states:
In particular, they *both *expect content of the form
key1=value1key2=value2
However, in a practical use case, wget performs no such checks and will
send any data you provide it with.
So then how to unify --post-data and --post-file into
Also, is the --post-file command really needed? Even if one does really
need to use POST data from a file, one could always cat the file inside
backticks as:
wget --options=POST `cat POSTdata` URL
Why not go with that?
Apparently always means something to you which is different
Okay, these are certain points that do not come instantly to me.
However, I never intended to break these. The above functionality would
remain for backward compatibility with old scripts.
I am simply debating on how to implement this as a new feature.
On Thu, Mar 7, 2013 at 10:07 AM, Steven M.
Darshit Shah dar...@gmail.com writes:
Okay, I just checked. The man page clearly states:
In particular, they *both *expect content of the form
key1=value1key2=value2
Good point. The man page should be changed make it clear that it's the
*server* that expects such post data when processing
I was addressing this feature request:
https://savannah.gnu.org/bugs/?37055
Which asks for an option to include the DELETE method in wget for RESTful
scripting.
Would the following syntax be the right way one would want to execute such
a command?
wget --delete URL pointing to resource that must
On 05/03/13 10:41, Darshit Shah wrote:
I was addressing this feature request:
https://savannah.gnu.org/bugs/?37055
Which asks for an option to include the DELETE method in wget for RESTful
scripting.
Would the following syntax be the right way one would want to execute such
a command?
On Tue, 5 Mar 2013, Ángel González wrote:
wget --delete URL pointing to resource that must be deleted
I would prefer something like --method=delete, which would also allow other
methods (eg. OPTIONS, TRACE, PROPFIND...)
Which incidentally is how curl does it (just with a differently named
Daniel Stenberg dan...@haxx.se writes:
On Tue, 5 Mar 2013, Ángel González wrote:
wget --delete URL pointing to resource that must be deleted
I would prefer something like --method=delete, which would also
allow other methods (eg. OPTIONS, TRACE, PROPFIND...)
Which incidentally is how curl
32 matches
Mail list logo
