Re: CURL SFTP wriitng Generations Data Sets(GDG) in MVS

On Wed, 9 Apr 2008, Masso Jr, James wrote:

>  I am currently trying to write a shell script in UNIX  using CURL SFTP

No, SFTP is not the same as FTPS. You use --ftp-ssl which is FTPS.

It matters because curl supports both SFTP and FTPS and using the wrong term 
makes things a bit confusin.

>> STOR UATGENS.xxxxxxx.wwwwwww(+1)
>
> < 550-SVC99 Return code=4 S99INFO=0 S99ERROR=1164 HEX=048C S99ERSN code
> X'00000000').
>
> < 550 Unable to create data set UATGENS.xxxxxxx.wwwwwww.G0045V00 for
> STOR command.

Ok, so curl sends the STOR command to upload a file and the server denies it 
to do that. This is rather a server issue than a curl issue. curl can only 
send the command and wish that the server grants it access.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

Re: metalink support

Daniel Stenberg wrote:
> A metalink file transfer library could be made as a layer on top of libcurl,
> and I think that is the only logical and sensible way.
>
> Adding metalink support to the curl tool however, seems like a very good idea
> to me...

Hi Daniel,

(I trust it's ok that I'm replying to this thread here)

Wonderful! Thanks for taking the time to reply and all your feedback
in the past!

I would love to see curl with metalink support. I'm certain that the
added attention of the curl community could only improve metalink.

Please let me know if there's anything I can do to make this happen.

The metalink docs are at http://www.metalinker.org/implementation.html#spec

--

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads

Re: metalink support

On Thu, 10 Apr 2008, Anthony Bryan wrote:

>> Adding metalink support to the curl tool however, seems like a very good 
>> idea to me...
>
> I would love to see curl with metalink support. I'm certain that the added 
> attention of the curl community could only improve metalink.
>
> Please let me know if there's anything I can do to make this happen.
>
> The metalink docs are at http://www.metalinker.org/implementation.html#spec

We basically need someone to step forward and start working on actually 
_implementing_ it. Unfortunately it will require some rather big changes in 
the code, which probably scares away most people.

This is not a particularly scratchy itch on my own back so I don't see myself 
diving into this task within the nearest future.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

RE: Web service server doesn't see posted data

>> However, when I tried the same approach with the NOAA weather service
with the
>> commands listed below, the call failed, with the server reporting it
didn't see
>> any parameters
>> 
>> --url
http://www.weather.gov/forecasts/xml/sample_products/browser_interface/
>> ndfdXMLclient.php
>> --data lat=45.550980
>> --data lon=-122.917359
>> --data product=time-series
>> --data begin=2008-04-08T15:00:00
>> --data end=2008-04-08T16:00:00
>> --data pop12=pop12
>> 
>> However, if I put the entire URI into the URL, it works just fine
>> --url
http://www.weather.gov/forecasts/xml/sample_products/browser_interface/
>>
ndfdXMLclient.php?&lat=45.550980&lon=-122.917359&product=time-series&beg
in=
>> 2008-04-08T13:00:00&end=2008-04-08T14:00:00&pop12=pop12
>
>
> The difference between the first and second commands is that the first
does
> a POST while the second does a GET. Add the -G option to the first one
>and it should work.

RE: Web service server doesn't see posted data

On Thu, 10 Apr 2008, Bruce, Henry wrote:

>> The difference between the first and second commands is that the first does 
>> a POST while the second does a GET. Add the -G option to the first one and 
>> it should work.

> However when I generated the libcurl source, I saw that the --get command 
> caused the post field data to be added to the URL. This implies that I 
> cannot use the curl_easy_setopt CURLOPT_POSTFIELDS option to set the web 
> service query string, but must append it to the url (as per the working 
> example above). This will work, but it makes the libcurl code messier. I 
> tried setting the CURLOPT_HTTPGET parameter to 1, but this failed as before. 
> Is there any way I can use the CURLOPT_POSTFIELDS option, or I must I create 
> the URI myself and use it as paramter for the CURLOPT_URL option ?

Now we took a large step into the land of libcurl and thus this is now rather 
a subject for the curl-library list...

But you're right. When you do a POST you provide the data to the 
CURLOPT_POSTFIELDS option and when you do a GET the entire data is passed in 
the URL. libcurl works this way because this is how HTTP URLs are designed to 
work and doing it any other way would be highly confusing if you ask me.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

--include and --head - option order is important

Greetings,

It appears as though when using -i and -I, you must specify -i after -I.

$ curl -I -i http://bashcurescancer.com
$ curl -i -I http://bashcurescancer.com
HTTP/1.1 200 OK
Date: Mon, 14 Apr 2008 03:11:35 GMT
Server: Apache/2.2.6 (Unix)
X-Pingback: http://bashcurescancer.com/wordpress/xmlrpc.php
Last-Modified: Mon, 14 Apr 2008 02:38:11 GMT
Connection: close
Content-Type: text/html; charset=UTF-8

I tested this with the latest version, curl-7.18.1 and confirmed this
situation still exists. I don't see anything in the manual about these
options having a required order (though I could have missed
something).

If this is indeed a bug, the fix, below, is trivial.

Thanks for you time,
Brock Noland

--- main.old.c  2008-04-13 16:10:49.000000000 -0500
+++ main.c      2008-04-13 16:13:32.000000000 -0500
 <at>  <at>  -2445,6 +2445,7  <at>  <at> 
         return err;
       break;
     case 'i':

Re: --include and --head - option order is important

On Sun, Apr 13, 2008 at 10:13 PM, Brock Noland <brockn <at> gmail.com> wrote:
> Greetings,
>
>  It appears as though when using -i and -I, you must specify -i after -I.
>
>  $ curl -I -i http://bashcurescancer.com
>  $ curl -i -I http://bashcurescancer.com
>  HTTP/1.1 200 OK
>  Date: Mon, 14 Apr 2008 03:11:35 GMT
>  Server: Apache/2.2.6 (Unix)
>  X-Pingback: http://bashcurescancer.com/wordpress/xmlrpc.php
>  Last-Modified: Mon, 14 Apr 2008 02:38:11 GMT
>  Connection: close
>  Content-Type: text/html; charset=UTF-8
>
>  I tested this with the latest version, curl-7.18.1 and confirmed this
>  situation still exists. I don't see anything in the manual about these
>  options having a required order (though I could have missed
>  something).
>
>  If this is indeed a bug, the fix, below, is trivial.
>
>  Thanks for you time,
>  Brock Noland
>
>  --- main.old.c  2008-04-13 16:10:49.000000000 -0500
>  +++ main.c      2008-04-13 16:13:32.000000000 -0500
>   <at>  <at>  -2445,6 +2445,7  <at>  <at> 
>          return err;
>        break;

Re: --include and --head - option order is important

On Sun, 13 Apr 2008, Brock Noland wrote:

> It appears as though when using -i and -I, you must specify -i after -I.

Thanks for pointing this out!

> If this is indeed a bug, the fix, below, is trivial.

I think I'll prefer to remove the use of two bits for that functionality as it 
is quite confusing. How about the attached patch ?

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

Index: src/main.c
===================================================================
RCS file: /cvsroot/curl/curl/src/main.c,v
retrieving revision 1.456
diff -u -r1.456 main.c
--- src/main.c	23 Jan 2008 06:11:11 -0000	1.456
+++ src/main.c	14 Apr 2008 13:20:29 -0000
 <at>  <at>  -200,7 +200,9  <at>  <at> 
 #define CONF_AUTO_REFERER (1<<4) /* the automatic referer-system please! */
 #define CONF_HEADER   (1<<8) /* throw the header out too */
 #define CONF_NOPROGRESS (1<<10) /* shut off the progress meter */
-#define CONF_NOBODY   (1<<11) /* use HEAD to get http document */
+#define CONF_NOBODY   (1<<11) /* get meta-data (headers) about the file
+                                 without transferring the body, use HEAD to
+                                 get http document */
 #define CONF_FAILONERROR (1<<12) /* no output on http error codes >= 300 */

Re: --include and --head - option order is important

On Mon, 14 Apr 2008, Brock Noland wrote:

>>  I think I'll prefer to remove the use of two bits for that functionality 
>> as it is quite confusing. How about the attached patch ?
>
> The patch works for me!

Thanks for verifying, this is now committed!

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

Re: --include and --head - option order is important

On Mon, Apr 14, 2008 at 8:25 AM, Daniel Stenberg <daniel <at> haxx.se> wrote:
>  I think I'll prefer to remove the use of two bits for that functionality as
> it is quite confusing. How about the attached patch ?

The patch works for me!

Thanks,
Brock