Re: [Bug-wget] Syntax for RESTful scripting options
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 commands have been turned into aliases. Internally they set --method=POST and --body-data or --body-file as applicable. * Added sanity checks to ensure that wget is not invoked with both, --body-data and -body-file or that it is not invoked with either of them but without a --method. * Added sanity check to ensure that wget is not invoked with method and --post-file or --post-data * Added missing sanity check to ensure that wget is not invoked with both --post-file and --post-data * Documentation for new commands. The major difference between this and the last submission is the removal of redundant code between body-data and post-data. -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani 0001-Add-a-generic-method-command-to-set-a-method-in-HTTP.patch Description: Binary data
Re: [Bug-wget] Syntax for RESTful scripting options
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 the code for
body-data / body-file is to set the options in main.c through setoptval().
However, much as I try, I haven't been able to understand the section of
the code that handles setting these options. This is what I tried, if
someone can help me out here, I'd be very thankful!
Since, two options need to be set for one command line parameter, I thought
about adding a non-standard option, OPT__ALIAS in struct cmdline_options
Change --post-file and --post-data in option_data to:
{ post-data, 0, OPT__ALIAS, NULL, required_argument },
{ post-file, 0, OPT__ALIAS, postfile, required_argument },
However, after this, I am unsure as to what parameters to pass to
setoptval().
All the calls to setoptval() have opt-long_name as their third argument,
but that isn't valid in this case, since opt-long_name will refer to the
original --post-* command.
On Sun, Apr 7, 2013 at 2:02 AM, Darshit Shah dar...@gmail.com wrote:
+ if (opt.method)
+{
+ request_set_header (req, Content-Type,
+ application/x-www-form-urlencoded,
rel_none);
+
+ if (opt.body_data || opt.body_file)
+ {
please indent '{' with two empty spaces.
Sorry, still not completely used to GNU's indentation method. I sometimes
slip up and forget that indent.
Currently mobile, I'll make the change as soon as I get access to a
machine.
+if (opt.body_data)
+ body_data_size = strlen (opt.body_data);
+else
+ {
+body_data_size = file_size (opt.body_file);
+if (body_data_size == -1)
+{
+ logprintf (LOG_NOTQUIET, _(BODY data file %s missing:
%s\n),
+ quote (opt.body_file), strerror (errno));
+ return FILEBADFILE;
+}
+ }
+request_set_header (req, Content-Length,
+xstrdup (number_to_static_string
(body_data_size)),
+rel_value);
+ }
+}
+
maybe the previous if (opt.post_data || opt.post_file_name) case can
be handled here?
What will break if we just do:
if (opt.post_data || opt.post_file_name)
{
opt.method = POST;
opt.body_data = opt.post_data;
opt.body_file = opt.post_file;
}
before you check for if (opt.method)?
Do you think we can get ride of the old code to handle POST data?
That would be possible, if we set opt.post_data and opt.post_file_name as
aliases to set opt.method=POST and opt.body_data or opt.body_file in
main.c
Otherwise, this will cause some inconsistent output, wherein in one place
it says Post-Data and in another wget outputs Body-Data.
That can however be avoided, if the line reads:
logprintf (LOG_NOTQUIET, _(%s data file %s missing: %s\n),
quote (opt.method), quote (opt.body_file),
strerror (errno));
However, since the code is explicitly checking for opt.method and
opt.post_data / opt.post_file_name in multiple places, this has a very high
chance of breaking if the server redirects.
I'll run some tests after the change and let you know.
In any case I can't still apply your patch upstream, I am waiting for
your copyright assignment papers to be processed (or received).
I have already sent the papers by snail mail. Wish there was a way to
submit them electronically.
--
Thanking You,
Darshit Shah
Research Lead, Code Innovation
Kill Code Phobia.
B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
--
Thanking You,
Darshit Shah
Research Lead, Code Innovation
Kill Code Phobia.
B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 --post-data / --post-file when invoked with
--method, wget will NOT fallback to GET upon a redirection request.
* Added sanity checks to ensure that wget is not invoked with both,
--body-data and -body-file or that it is not invoked with either of them
but without a --method.
* Added sanity check to ensure that wget is not invoked with method and
--post-file or --post-data
* Added missing sanity check to ensure that wget is not invoked with both
--post-file and --post-data
All the changes have been squashed into one single commit. In case it is
preferred to send them as separate commits, I will do the same.
On Sun, Mar 17, 2013 at 12:45 PM, Darshit Shah dar...@gmail.com wrote:
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.
These two are the same functionality, why not merge it internally. Only
issue is, how to do it efficiently?
I am unable to understand who to set two flags through setoptval() for a
given command without putting an if condition in there.
On Sun, Mar 17, 2013 at 2:04 AM, Giuseppe Scrivano gscriv...@gnu.orgwrote:
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 that executes the old --post-data and
--post-file commands.
great work! Just some comments:
+else if (opt.method)
+ {
+char *q;
+int s = strlen (opt.method);
+for ( q = opt.method; s=0; ++q, s-- )
+ *q = c_toupper (*q);
+meth = opt.method;
+ }
this could be simplified as:
for (q = opt.method; *q; ++q)
then you don't need s at all.
The new flags should be documented, could you add also the documentation
for those?
Cheers,
Giuseppe
--
Thanking You,
Darshit Shah
Research Lead, Code Innovation
Kill Code Phobia.
B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
--
Thanking You,
Darshit Shah
Research Lead, Code Innovation
Kill Code Phobia.
B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
0001-Add-a-method-command-to-set-a-Method-to-use-in-the-H.patch
Description: Binary data
Re: [Bug-wget] Syntax for RESTful scripting options
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.
These two are the same functionality, why not merge it internally. Only
issue is, how to do it efficiently?
I am unable to understand who to set two flags through setoptval() for a
given command without putting an if condition in there.
On Sun, Mar 17, 2013 at 2:04 AM, Giuseppe Scrivano gscriv...@gnu.orgwrote:
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 that executes the old --post-data and
--post-file commands.
great work! Just some comments:
+else if (opt.method)
+ {
+char *q;
+int s = strlen (opt.method);
+for ( q = opt.method; s=0; ++q, s-- )
+ *q = c_toupper (*q);
+meth = opt.method;
+ }
this could be simplified as:
for (q = opt.method; *q; ++q)
then you don't need s at all.
The new flags should be documented, could you add also the documentation
for those?
Cheers,
Giuseppe
--
Thanking You,
Darshit Shah
Research Lead, Code Innovation
Kill Code Phobia.
B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 that executes the old --post-data and --post-file
commands.
great work! Just some comments:
+else if (opt.method)
+ {
+char *q;
+int s = strlen (opt.method);
+for ( q = opt.method; s=0; ++q, s-- )
+ *q = c_toupper (*q);
+meth = opt.method;
+ }
this could be simplified as:
for (q = opt.method; *q; ++q)
then you don't need s at all.
The new flags should be documented, could you add also the documentation
for those?
Cheers,
Giuseppe
Re: [Bug-wget] Syntax for RESTful scripting options
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. I think these commands should be set as an alias to --body-data and --body-file. While that is easily done by editing the commands[] array in main.c the issue is, how best to set opt.meth od to POST. Putting a conditional in setoptval() would be a terrible idea since it causes an extra condition evaluation everytime for just one particular case. But I am unable to think of any other method to merge the two internally. Please do suggest something. On Mon, Mar 11, 2013 at 8:14 PM, Giuseppe Scriuvano gscriv...@gnu.orgwrote: 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 them as deprecated. Let's live with them for now. Cheers, Giuseppe -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani implementMethod Description: Binary data
Re: [Bug-wget] Syntax for RESTful scripting options
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 compatibility. No. I won't. As suggested by Hrvoje, I plan on implementing as: --method=POST:data... --method=POST,file:filename... I will work on this and send a patch in ASAP. -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 --post-data and --post-file; we can't drop these for backward compatibility. No. I won't. As suggested by Hrvoje, I plan on implementing as: --method=POST:data... --method=POST,file:filename... what is the advantage over reusing --post-data and --post-file? Giuseppe
Re: [Bug-wget] Syntax for RESTful scripting options
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 all under one heading. so please use --body-file and --body-data. What's the problem with them? Cheers, Giuseppe
Re: [Bug-wget] Syntax for RESTful scripting options
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, I'll implement them as a separate command without the use of a new delimiter. In fact I would personally prefer to keep it that way without adding extra complexity to the code in adding a new delimiter. On Mon, Mar 11, 2013 at 7:42 PM, Giuseppe Scrivano gscriv...@gnu.orgwrote: 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 all under one heading. so please use --body-file and --body-data. What's the problem with them? Cheers, Giuseppe -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 them as deprecated. Let's live with them for now. Cheers, Giuseppe
Re: [Bug-wget] Syntax for RESTful scripting options
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 the proposed options influence the sending of request body, how about: --request-body=... and --request-body-file=...? This also removes the need to have two pairs of identical options only because the method is mentioned in the name of the option. 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 That way both --post-data and --post-file would become deprecated and no new options would be needed.
Re: [Bug-wget] Syntax for RESTful scripting options
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 --method=POST,data:a=1b=2 instead? Just a thought. Tony
Re: [Bug-wget] Syntax for RESTful scripting options
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 other cases wget expects the URL next. The GET option is included only for completeness. Please do let me know if I'm missing something. Even easier, just accept anything as method, and send that (changing to uppercase). --post-data and --post-file would also work for put, but you may set --put-data --put-file as aliases for niceness. Also, as Tim pointed out, wget does not test whether the file exists. I'll patch that too. Good to fix that. But don't try to do everything in one big patch, send one per feature.
Re: [Bug-wget] Syntax for RESTful scripting options
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 correctly. Attaching the patch file that adds this functionality. I am not shure, that a test for --method is needed. Do you want to see Wget generate a DELETE request if you use --method=DELETE ? Just use -d ;-) But to answer your request: You have to make HTTPServer.pm accept and answer DELETE requests (and POST would be nice then, too). Make a copy of a .px test and change the options of the wget command. [just something personal] I just did that for POST, but I can't see any benefit to add such a test. And perl *really* sucks to me (but hey, i am a C and Java programmer). It took me 45 minutes to understand the perl syntax + the existing test environment code... that is far too much for such a simple test environment. In fact, after that, the actual code change took me 3 minutes. But I know, I forget all about perl within hours or at least days... perl is hack and forget and a waste of time (to me, not to everyone). I would prefer a C test environment for a C project, having tests written in C. Regards, Tim
Re: [Bug-wget] Syntax for RESTful scripting options
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 non-UNIX(-like) systems (VMS, for example), where such UNIX(-like) shell tricks are not available. Even on UNIX(-like) systems, some old shells may have limited command-line length. Some users might not want the contents of their file exposed to every user on the system who can run ps. How many reasons do you need not to wreck existing functionality? Or people may simply want to send a newline in the post data. So then how to unify --post-data and --post-file into one option? I too am not a bid advocate of changing the meaning according to the content but that seemed like the easiest way forward. Don't do it.
Re: [Bug-wget] Syntax for RESTful scripting options
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 feature. So, wget just needs one new option --method=DELETE| It replaces POST method by DELETE in the request. That is, --method comes (or maybe not, see below) together with either --post- data or --post-file. Regarding the one option to aggregate --post-file and --post-data, I agree with the others: Wget must know (and not guess) if the user addresses a file or data. Everything else could cause havoc. BTW: How can Wget create a POST without any data (without Content-Type and Content- Length) ? Curl can... curl --request DELETE 'http://localhost:8000/xxx' sends: POST /xxx HTTP/1.1 User-Agent: curl/7.29.0 Host: localhost:8000 Accept: */* There is another Wget issue: If the file given by --post-file does not exist, wget still sends a request... that could cause havoc and IMHO should be fixed. At least with --method=DELETE it is definitely dangerous. $ wget --post-file xx 'http://localhost:8000/xxx' --2013-03-07 09:30:02-- http://localhost:8000/xxx POST data file 'xx' missing: No such file or directory Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:8000... connected. HTTP request sent, awaiting response... resulting request: POST /xxx HTTP/1.1 User-Agent: Wget/1.14 (linux-gnu) Accept: */* Host: localhost:8000 Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Content-Length: 0 OT (I just see it): Why does Wget send 'Connection: Keep-Alive' here ? It is not needed and causes unecessary impact on the server... Regards, Tim
Re: [Bug-wget] Syntax for RESTful scripting options
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 always, you can customize both headers using the `--header' option, but I don't think you can remove them entirely. Maybe the `--header' syntax could be extended so that `--header=NAME' (note lack of trailing colon -- currently illegal) could be used to delete the generated header from the HTTP request. resulting request: POST /xxx HTTP/1.1 User-Agent: Wget/1.14 (linux-gnu) Accept: */* Host: localhost:8000 Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Content-Length: 0 OT (I just see it): Why does Wget send 'Connection: Keep-Alive' here ? It is not needed and causes unecessary impact on the server... Because Wget tries to reuse the same connection for multiple requests. For example, the server can respond with a redirection, which would require a new request, best carried out on the same connection. (Plus, the code at that point doesn't have the information that it is the last request that will be run.)
Re: [Bug-wget] Syntax for RESTful scripting options
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 does not exist in the key:value format, assume that to be a file path and try to read that file. If the file does not exist, return an error. The old --post-data and --post-file commands will be kept for backward compatibility but marked deprecated. Please let me know if anyone has any sort of objection to this. On Wed, Mar 6, 2013 at 2:42 AM, Giuseppe Scrivano gscriv...@gnu.org wrote: 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 does it (just with a differently named option): $ curl --request DELETE http://example.com/ I agree here, it seems like the way to go. -- Giuseppe -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 try to read that file. If the file does not exist, return an error. To me, that sounds like the wrong path to go. You can send whatever you want in a post, there's no magic key:value format in HTTP. What if you want to just send the string /dev/null in the POST? It is not key:value and it is an existing file path... -- / daniel.haxx.se
Re: [Bug-wget] Syntax for RESTful scripting options
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, and quite simply not something wget should restrict like that. There are lots of use-cases for doing POST with data formatted in other ways. Just my opinion of course. -- / daniel.haxx.se
Re: [Bug-wget] Syntax for RESTful scripting options
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 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 try to read that file. If the file does not exist, return an error. To me, that sounds like the wrong path to go. You can send whatever you want in a post, there's no magic key:value format in HTTP. What if you want to just send the string /dev/null in the POST? It is not key:value and it is an existing file path... -- / daniel.haxx.se
Re: [Bug-wget] Syntax for RESTful scripting options
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 entity-body then the data can be still passed trough --post-data or --post-file. I don't really like the idea of an argument that can have different meanings according to its content, in this case presence or not of ':'. What would be the advantage of dropping them? -- Giuseppe
Re: [Bug-wget] Syntax for RESTful scripting options
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 --post-file, it just sends it as-is. It does default the content-type to application/x-www-form-urlencoded, but this is easily overridden with the --header option.
Re: [Bug-wget] Syntax for RESTful scripting options
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 one option? I too am not a bid advocate of changing the meaning according to the content but that seemed like the easiest way forward. 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? On Thu, Mar 7, 2013 at 2:58 AM, Giuseppe Scrivano gscriv...@gnu.org wrote: 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 entity-body then the data can be still passed trough --post-data or --post-file. I don't really like the idea of an argument that can have different meanings according to its content, in this case presence or not of ':'. What would be the advantage of dropping them? -- Giuseppe -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 from what it means to me. It may be hard to believe, or you may not care, but some folks use this program on non-UNIX(-like) systems (VMS, for example), where such UNIX(-like) shell tricks are not available. Even on UNIX(-like) systems, some old shells may have limited command-line length. Some users might not want the contents of their file exposed to every user on the system who can run ps. How many reasons do you need not to wreck existing functionality? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: [Bug-wget] Syntax for RESTful scripting options
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. Schweda s...@antinode.infowrote: 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 from what it means to me. It may be hard to believe, or you may not care, but some folks use this program on non-UNIX(-like) systems (VMS, for example), where such UNIX(-like) shell tricks are not available. Even on UNIX(-like) systems, some old shells may have limited command-line length. Some users might not want the contents of their file exposed to every user on the system who can run ps. How many reasons do you need not to wreck existing functionality? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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 HTML forms, but that they are in no way inherent to HTTP or to Wget (except for the default Content-Type, which can be overridden). So then how to unify --post-data and --post-file into one option? Why would it need to be one option when they do different things? Perhaps I'm missing something, but --method=POST --post-data=foo (or --post-file=bar) seems fine to me. If you want to be able send arbitrary contents with requests, those can be renamed to `--request-data' and `--request-file', keeping the old options for compatibility.
[Bug-wget] Syntax for RESTful scripting options
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 be deleted Or should there be anything more? -- Thanking You, Darshit Shah Research Lead, Code Innovation Kill Code Phobia. B.E.(Hons.) Mechanical Engineering, '14. BITS-Pilani
Re: [Bug-wget] Syntax for RESTful scripting options
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? wget --delete URL pointing to resource that must be deleted Or should there be anything more? I would prefer something like --method=delete, which would also allow other methods (eg. OPTIONS, TRACE, PROPFIND...) OTOH, delete has a clear mapping for also being implemented for ftp.
Re: [Bug-wget] Syntax for RESTful scripting options
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 option): $ curl --request DELETE http://example.com/ -- / daniel.haxx.se
Re: [Bug-wget] Syntax for RESTful scripting options
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 does it (just with a differently named option): $ curl --request DELETE http://example.com/ I agree here, it seems like the way to go. -- Giuseppe
