[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTPAPI http_use_cookies



Sender: craigs@xxxxxxxxx

Wow!  Great and detailed responses.  Thanks Scott!
It sounds like FTPAPI may be the thing for me to use instead of HTTPAPI in
order to have the file control of FTP.  I didn't understand before the
HTTPAPI was doing program calls on the remote server.  I also hadn't really
looked into FTPAPI thinking it was a wrapper for the IBM FTP client.  I
also have my own wrapper that does FTP script on the fly and allows
checking for errors during the FTP script execution.  I guess an analogy to
that would be the MONMSG of CL.  It sounds like FTPAPI could really
overcome the IBM FTP client restrictions.  I will have to look into this.
Yes, I was in the wrong mindset thinking I was doing file manipulation
instead of program calls.  I didn't know you could code for both types of
redirects.  Excellent!
The redirect in the response of '/?T' took me to the root of the IFS on my
own system.  I was using HTTPAPI 1.15 as I have verified.  Maybe it is not
quite right yet?  Why did I receive this in the stream file post response
when I thought I would receive something about being okay?  Was the
response I got normal?  If so, then why didn't the previous http_url_get
loop come back with the 302.  Maybe I should have done the http_url_post()
thing before the http_url_get loop like you showed.  That appears to be the
start of the checking.  I'm thinking that may be it.
Thanks again for all your help, Scott!

Craig Strong


                                                                           
             Scott Klement                                                 
             <sk@xxxxxxxxxxxxx                                             
             com>                                                       To 
             Sent by:                  ftpapi@xxxxxxxxxxxxx                
             owner-ftpapi@xxxx                                          cc 
             e.ods.net                                                     
                                                                   Subject 
                                       Re: HTTPAPI http_use_cookies        
             04/07/2006 03:03                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             ftpapi@xxxxxxxxxx                                             
                    net                                                    
                                                                           
                                                                           




Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


> I am planning on switching from secure FTP to HTTPAPI for the sole reason
> of not tying up the FTP application's certificate with other future
> possible secure FTP sites.  I have heard if we want to do secure FTP with
> another site, we cannot assign an additional certificate to the FTP
client
> and have it know which one to use for which site.

That's a limitation of IBM's FTP client for the iSeries, and not a
limitation of FTP in general.  If you wanted to add SSL support to FTPAPI,
or get one of the others who have suggested that we add SSL support to add
it, then you could easily overcome this restriction.  Heck, if I had
access to IBM's code for their FTP client, I could fix the problem in a
matter of hours.


> Then came the attractiveness of HTTPAPI which can tie a certificate to a
> user application.  The main unattractiveness I see in HTTPAPI is in
> handling generics.
>
> I think the users can live with that though since the generic receival
> transactions will be probably monthly rather than the non-generic sends
> done weekly or more.  What I mean by generics is simulating the FTP
> "mget '/<file*>'" where the file starts with certain characters.

HTTP isn't FTP.  FTP is a protocol that's designed to give you a shell
where you can get a list of files, do renames, deletes, uploads,
downloads, etc.  That's it's purpose.

HTTP is designed to transport hyperlinked documents.  It's not intended to
be an interactive shell.

If you wanted a way to list files, you'd write a server-side program or
script that listed files.  You could certainly have generics included,
since you're writing the code, that'd be up to you.  If you did that,
HTTPAPI would be able to use it, no problem.

So, your complaint isn't really with HTTPAPI, it's with the fact that HTTP
isn't FTP and doesn't have a built-in mechanism for working with files in
a directory.


> Also, doing an FTP delete through HTTPAPI I don't see.  For the send
> process, it is wonderful and should work for us.  Am I correct in my
> thinking so far? Make sense?

HTTPAPI isn't an FTP client, and it's not designed to be one.  I could
understand your complaint if FTPAPI didn't have a delete function, since
deleting files is a standard thing in FTP.  But HTTP is not designed as a
generic "work with files" protocol.

What would HTTPAPI send to the server in order to request a generic file
listing?  Or to request a file be deleted?  There's no such mechanism in
the protocol.

You could write a program that runs on the server that deletes files, and
it could accept parameters that tell which files to delete -- but that
won't be part of every server or part of the HTTP protocol.  It'll be one
program running on the servers where it has been installed.  And HTTPAPI
_would_ be able to talk to it and tell it which files to delete, you'd
just have to format them as parameters to a program rather than using an
"HTTP_delete" API.

So, in my opinion, you're in the wrong mindset, and therefore your
statements don't make sense.

> I used HTTPAPI for the first time to post a stream file to
> https://sft.wellsfargo.com and it seemed to transfer fine but I have
> some questions. I am going to use http_use_coookies(*on) instead of the
> exit points like in EXAMPLE12.

Yes,the cookie support in HTTPAPI is much more correct than the quick-fix
in EXAMPLE12.


> I was able to use certificates and go to https://sft.wellsfargo.com and
> upload my file.  When I had my program on debug I did not notice any
> "302" redirects.  Could the website change and start redirecting?

Craig... you're calling a program on Wells Fargo's computer.  That's what
you're doing.  HTTPAPI is just the mechanism using to call it.  It can't
tell that program what to do with the data you send, or what sort of
response to send back.  All it does is provide the mechanism for making
the call.

Let's say you bought software from a vendor that prices the products you
sell.  From your programs whenever you want to know the price of a
product, you code this:  CALL PGM(VESOFT/PRICEPROD) PARM(&PROD &PRICE).

Would you call IBM and say to them "Hi IBM!  You wrote the CALL command
for OS/400.  If I call a program named PRICEPROD, will it's parameters
ever change?  How will I know if they change?  Or should I just wait to
see if my program blows up?"

No.  You wouldn't ask IBM, just because they wrote the CALL command, what
parameters the software would return.  You'd call the company who wrote
the PRICEPROD program.

The same is true in this case.  HTTPAPI gives you the ability to call a
program on Wells Fargo's system.  You don't ask the guy who wrote HTTPAPI
whether or not Wells Fargo will ever change their system to return the
results differently!  You ask Wells Fargo.


> If so, how would I know to have code in place to redirect with cookies
> in EXAMPLE12 rather than http_redir_loc in EXAMPLE13?
> Just wait until my program blows up to figure it out?

Again, it's Wells Fargo's decision as to how they respond to your request.
If they send a redirect, they have two choices, they can send a 302 or 303
response code and a Location: header to tell the caller that they want to
redirect to a different page.   Or they can simply return the results.

It's up to them, not up to me, which one they do.  If you want to code for
both possibilities, then do that  It should be easy enough to do:

     rc = http_url_post( . . . );
     if (rc = 302 or rc = 303);
        url = http_redir_loc();
        rc = http_url_get( url . . .);
     endif;

> I will probably be using the method Dave Parnin is using to send to
> Wells Fargo but this is a new website so I'm not sure how they will be
> sending redirects.  The code is:
> http_use_cookies(*on);
> dou rc <> 302
> and rc <> 301;
>   rc = http_url_get(url: '/tmp/httptest.html');
> enddo;

Hmmm... my only concern with this is that you could possibly get stuck in
an endless loop.  You might want to do something to make sure that doesn't
happen...  maybe keep a count of the number of redirects and abort if it
gets to be more than 5 or 6...  just to be sure.

    http_use_cookies(*ON); <-- do this once at the start of your program.

    rc = http_url_post ( . . .)
    count = 0;
    dou rc<301 or rc>303 or count>5;
      count = count + 1;
      url = http_redir_loc();
      rc = http_url_get( . . . );
    enddo;

    if rc>=301 and rc<=303;
      errormsg = 'Got stuck in redirect loop!';
      // send errmsg to user or log
    endif;

> and remove the http_use_cookies(*on)?  What about the "301" in the
example.
> Should that be part of the "if" for EXAMPLE13?

IIRC, 302 and 303 are redirects.    301 means "moved permanently" and
technically, you shouldn't do an automatic redirect if 301 is returned
from a POST request.  However, some servers still use the HTTP/1.0
behavior, which did a GET request when a 301 is received.

By contrast 303 is new to HTTP/1.1  The problem with 303 is older browsers
won't understand it and won't know what to do with it.

Because of this, almost all servers send 302 for redirect :)

>
> I did notice a "302 Found" in the response XML from the
http_url_post_stmf.
> The details: "The document has moved <A HREF=" /?T " >here</A>.<P>
> When clicking on the underlined here in Internet Explorer, it took me to
> the root of my own server.  Is that normal?

The redirect of '/?T' shouldn't take you to your own server, it should
take you to the root of whichever server sent the redirect.  HTTPAPI 1.15
does understand these "relative links", but versions prior to 1.14 did
not.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------