Redo for Patch for cookie processing in Flood, file flood_round_robin.c, function round_robin_postprocess() [Ref A5]

[Norman Tuttle <nt...@photon.poly.edu>]

As per the suggestions I have received, I am resubmitting the attached
diff for the cookies changes in the proper format.
See the inline comments for what has been fixed by this patch.

Note that this patch alone does not provide the most robust solution as it
ignores the possibility of different cookies with the same name going
to different hosts, but for this and observation of expiration dates, etc,
we would have to expand the Flood model of cookies to store that
information as well, which is currently not being done. Perhaps somebody
can add these capabilities. The patch did resolve issues that we had with
client sites regarding our handling of cookies.

-Norman Tuttle, developer, OpenDemand Systems ntuttle@opendemand.com

Re: Redo for Patch for cookie processing in Flood

[Jacek Prucia <ja...@acn.waw.pl>]

On Tue, 28 Oct 2003 10:12:19 -0500 (EST)
Norman Tuttle <nt...@photon.poly.edu> wrote:

Hello Norman,

> As per the suggestions I have received, I am resubmitting the attached
> diff for the cookies changes in the proper format.
> See the inline comments for what has been fixed by this patch.

Please see attached diff. It's basically your patch with some minor
corrections:

1. Follow style guide more closely
2. Remove some comments
3. Replace respend with headers end. Do a test for page that has 'Set-Cookie:'
   string in its body to see why :)

If those small changes are OK with you, I'll commit your patch soon.

> Note that this patch alone does not provide the most robust solution as it
> ignores the possibility of different cookies with the same name going
> to different hosts, but for this and observation of expiration dates, etc,
> we would have to expand the Flood model of cookies to store that
> information as well, which is currently not being done.

Yup. Besides that we need to check for Set-Cookie2: header, and allow for
custom (specified in configuration) cookies to be sent. Anyway your patch is a
step towards right direction.

I'll try to review a bunch of your other patches. I'm really sorry, that this
takes sooo long, but I'm dead busy with work. Looks like this holds true for
other flood dev'ers (because of that we haven't released flood-1.1 to
public!). Anyway, your patches have a nice, quiet place on my disk until I get
more free time to spent on flood development.

regards,
--
Jacek Prucia

Re: Redo for Windows build issues [Ref A0]

[Norman Tuttle <nt...@photon.poly.edu>]

Without the changes to these 3 files which I make in the diffs, I could
not get Flood to compile under windows. Note that a debug version
generally would require more manipulation if you want to compile it within
the Visual C++ debugger (would likely use static directories rather than
attempting to feed through the environment which is not well supported).

Besides for Makefile.win and flood.dsp which I previously provided, I am
also providing the "patch" for XLATE.C. Please note the reference to my
original email below that this is a kludge:

> Fixing the inconsistency between the files XLATE.C (which was using
> APU_HAS_APR_ICONV) and APU.H (which has APU_HAVE_APR_ICONV set to 1 for
> Win32) by consistently using the "HAVE" version appears to have broken the
> build for Win32 because the presumed structure apr_iconv_t is never
> defined in the code space. I had to globally modify APU_HAVE_APR_ICONV
> back to the old value APU_HAS_APR_ICONV for XLATE.C to get it to continue
> to build. I assume this is the not the correct solution but it serves as
> the bandaid because I do not know what this structure is supposed to
> contain (the code I have from last year sheds no light on it either).

-Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com