Re: HTTPAPI http_use_cookies

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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
-----------------------------------------------------------------------