Re: Suggestions for the HTTP API (and Questions)

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


Hi Marc,

Glad to see you here.

> I am not familiar with how many people are on this list, but this is my
> first post to it so please be patient with me :>  I would like to start off
> with some general suggestions in light of the changes that I make to the
> API locally.

In my opinion, you should try not to make changes to the API unless you
intend to contribute them back to the project.  The reason I say that is
that now each time you run a new version of HTTPAPI, you'll have to make
those same changes before you can use it.   And, if someone else changes
the code, your changes could conflict.

This is an open-source project, and we'd appreciate it if you'd contribute
your changes by either posting them to the mailing list (if they're small)
or putting them on-line and providing a link (if they're large)

If you cannot put them on-line, you can send them to me, and I'll put them
on-line.


> 1) I would suggest at some point replacing peUserAgent, peContentType and
> peSOAPAction with a single parm: peHeaders.  This allows the programmer to
> decide what extra headers to include without having to modify the API.  One
> of the sites we access requires 3 or 4 specialized headers, and the
> addition of the SoapAction header parm illustrates to me the potential need
> for many more parms.  This change would not be very backwards compatible,
> but would be very forwards compatible :>

It's my firm belief that people should not need to understand HTTP headers
to use HTTPAPI.

For the more advanced programmers, I added the ability to specify an "exit
proc" (call-back function) so that they can specify any header that they
like.  This functionality will be available in version 1.9.  (1.9 was not
released yet, but you can get the beta version here:
http://www.scottklement.com/httpapi/beta/httpapi.savf  the code was
written back in October)

This should satisfy your requirement as well as protecting backwards and
forwards compatibility.


> 2) Have https_init() clear wkEnvH when it fails (except in the case where
> it has already been initialized).  For those who use named activation
> groups, not clearing it results in an inability to retry the operation
> after the problem which caused it to fail has been fixed.

Please post (or send me) your code for this.  It sounds like a bug that
should be fixed...


> 3) Have the automatic registration function register the application ID as
> a client rather than a server (the default).  I have a code snippet which
> does this FWIW...

When I wrote the registration code I was on a V4R5 box where there was
only one type of registration with the DCM.  In V5 they changed it to have
both client & server separately.

I'd like to see your code -- particularly if it doesn't break
compatibility with V4R5.  (Though, we can use /if defined() and friends to
make it compatible if necessary)


> Now here are my questions:
>
> 1) How does everyone deal with the fact that authority is needed for the
> certificate store file in order to establish an SSL connection?  I looked
> up gsk_secure_soc_open and it says you need to have authority to it, but an
> IBMer that I spoke to said that they use GSKit for their client side secure
> FTP and the users do not need authority to those files.  In fact he
> insisted that no authority was needed (I tested it thoroughly later and
> determined that yes it was (as documented)).  Have you all found this to be
> the case?  If not would you be able to let me know some info on your config?

Huh?  The documentation for gsk_secure_soc_open() clearly states that no
special authority is required.

From the V5R2 information center: "Service Program Name:
   QSYS/QSOSSLSR  Default Public Authority: *USE"  "Authorities: No
   authorization is required."

The only caveat that I know of is that the user must have authority to
read the stream files in the IFS where the certificates and keys are
stored by the digital certificate manager...   I granted them access using
the standard QShell CHOWN command.

It's been a long time since I did that and my mind is a little fuzzy, but
I think all I did was:
    STRQSH CMD('chown -R 755 /QIBM/UserData/ICSS/Cert')


> 2) The 1.8 version removed the 'connection: close' from the requests.  This
> broke an existing app for me where the program hangs on the select in
> ssl_recvdoc if the connection close is not specified.  I can provide a
> sample URL and postdata if someone wants to try it.  I was able to work
> around it (by specifying connection: close in my peHeaders parm), but it
> makes me worry as to how to determine when it is needed and when it is
> not.  I did notice the content length returned when it was missing was 306
> versus 700 when that header was provided, so I don't know to what extent it
> is something strange happening on the remote end.

According to RFC 2616, "connection: close" is not required and removing it
should not break anything.

I removed it because people were finding that data was getting truncated
with certain (IMHO, buggy) versions of Microsoft IIS.

Let me see your URL, though.  If removing connection:close is breaking
something, I'd like to see if I can determine when and why so we can
account for it in the future.

Of course, the call-back function that I mentioned earlier would also
allow you to specify connection: close.   I believe Ian Patterson is
already using this..


> 3) When connecting to one site with POST (and it returns chunked output) it
> returns an error code of 200 instead of 100, which causes the call to
> fail.  This is as a result of the post data being empty.  Is this something
> the remote server should handle or should the API not expect the
> 100-continue if the postdata length was zero?

Hmmm...  a post with no data?  Why not just do a GET in that case?

At any rate, 200 means "success" and, in fact, HTTPAPI should *never*
return 200 -- that would be a bug.

Here's the code I'm looking at from the end of do_post():

c                   if        rc<1 or wwFinRC=200
c                   return    rc
c                   else
c                   callp     SetError(wwErrorNo: wwErrorMsg)
c                   return    wwFinRC
c                   endif

Since rc can only be -1, 0 or 1, I don't see how it could ever return 200?
Please tell me how to reproduce this error.

Thanks for your input!

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