[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compressed HTTPS
Hi Ian,
I have not incorporated compression into HTTPAPI. Compression is
typically negotiated between the client/server, so even if your server
supports it, HTTPAPI would negotiate that no compression be used, and
would still work.
If you want to add compression support to HTTPAPI, you'd need to get
your hands on some compression libraries for IBM i, such as gzip and
deflate. IBM does provide a version of gzip with their GNU Utilities
for QShell -- but unfortunately, they only provide it in the form of a
program, which would have to be spawned and connected with pipes (ala
UnixCmd). The cost of spawning the process would almost certainly be
higher than the compression saved you. You'd really need to get the
compression tools in a *SRVPGM form.
Once you did that, though... you could change the code in HTTPAPI (in
SendDoc, RecvDoc) to use it if it's negotiated.
On 5/17/2011 12:51 PM, Ian Patterson wrote:
> The service where we have successfully used HTTPAPI and https for many years
> are concidering going to 'compressed' https. They have not yet issued any
> tech data on this requirement.
>
> I can't find much info on this and may have got the terminology wrong.
>
> Has anyone heared of or used this. ?
>
> If so is it supported within HTTPAPI ?
>
> Regards
>
> Ian Patterson
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------