RE: HTTPAPI and Cookie support

["Grizzly Malchow" <grizzlym@xxxxxxxxxxxxxxxxxxxxx>]

Sender: "Grizzly Malchow" <grizzlym@xxxxxxxxxxxxxxxxxxxxx>

Although I don't have a need for it right now, I'd be happy to help with
testing.
Griz 

-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Tuesday, January 24, 2006 2:30 PM
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: HTTPAPI and Cookie support

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


I haven't received any responses to the following message.  Does that
mean 
that nobody is interested in cookie support?

---
Scott Klement  http://www.scottklement.com



On Fri, 20 Jan 2006, Scott Klement wrote:
>
> I now have a project (for my "real" job) where I'll need HTTPAPI to
handle 
> cookies.
>
> It's true that you can handle them manually with xproc's, but I'm
thinking 
> that I'd like to add support into the project itself that takes care
of all 
> of the work of parsing them, saving them, tracking which hosts they
belong 
> to, determining which ones to send back to the server, etc.
>
> My thoughts so far are:
>
> a) Make this something an application program can turn on and off.
>
> b) Once the cookies have been parsed from the headers, store them in
memory 
> in a "cookie cache".  According to the specs, there are some cookies
that 
> should never be saved to disk, but should be discarded when the
browser 
> closes.  My thought for HTTPAPI would be to keep these "temporary
cookies" in 
> memory until the activation group is reclaimed, that way you can use
them for 
> multiple connections to a web site (without that, they're useless) but

> they're not "permanent".
>
> c) Have an option that the application can call to specify a file in
the IFS 
> that cookies can be saved to and/or loaded from.  With a browser,
cookies 
> will be kept separate per-user, but with HTTPAPI where every calling
RPG 
> program is really it's "own browser" HTTPAPI needs to know how to keep
things 
> separate between applications.  I figure by letting the application
supply 
> the filename, the app has complete control over how much it shares
it's 
> cookies with others.
>
> d) If no filename is given, HTTPAPI will simply treat all cookies as 
> temporary (as in point B, above)
>
> e) To provide better integration with applications, I'll provide an
API for 
> the application to retrieve a cookie value send by the server.
>
> Anyone have any comments on this?   Do you think an application should
have 
> the ability to create cookies that get sent to the server as well?
Normally a 
> cookie would only be created if the server tells the client to do so,
so I'm 
> not sure that this makes sense.
>
> Is there anyone who needs this support who might want to help me with 
> testing?
>
> ---
> Scott Klement  http://www.scottklement.com
>
-----------------------------------------------------------------------
> 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
-----------------------------------------------------------------------

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