We've been putting together a new piece of software recently and have butted heads with what look like a couple of issues with CGIUTL and larger POST parameters.

As far as I can tell, there is no issue with CGIOP_GETPAR, and retrieving a specific named parameter. The issues arise with both CGIOP_GETPARX and CGIOP_GETPARARY, but in different forms.

CGIOP_GETPARX appears to have issues with very large parameters, and past a certain size crops the rest of the parameters.

CGIOP_GETPARARY seems to have two i issues. First it doesn't appear to handle passed parameters, but will function perfectly well if you read the stdin into a variable and pass that as the optional string for it to handle. The second issue appears to be that the automatic decoding of the parameters doesn't happen if the passed parameter is too large. This one can be easily fixed by passing everything through a decoding process, but it would be nice to not have to do this unnecessarily.

This is currently happening on a 6.2.1426.1 release. Annoyingly I don't have a system up with 6.3 at the moment to try it on there.

Looked deeper into it, the automatic decoding with CGIOP_GETPARARY is failing if the parameter is larger than 2048 bytes.

Indeed, the decoding is using a convenient multi-purpose buffer that happens to be 4K in size, but to allow for the expansion during the decoding process, it only works up to 2K. That obviously needs to be fixed, and will be shortly. Do you need it in 6.2 or can you use this as incentive to move to 6.3?

As for the other issue(s), I need to study them a bit further before figuring out what needs to be done.

In the meantime, enjoy your weekend.

6.2 would be ideal for now, don't think we're quite ready for a 6.3 yet unfortunately.

You have a good weekend too! I have a lovely weekend of digging through mud to look forward to. Kate wants a patio, so my lot is to toil away in the winter weather!

You got it. And may I suggest you neither tarry nor grumble too loudly; as they say: happy wife, happy life. (And besides, it's still got to beat Christmas shopping!)

I wasn't able to reproduce the problem with CGIOP_GETPARARY using a passed string (in place of stdin). Perhaps I misunderstood that, but you can try it in the test program CGIUTL.BP .

But I think the 2K limit issue is resolved in 6.2.1428.9, for which I've posted beta copies for you to test...

ash-6.2.1428.9-w32-upd.zip
ash-6.2.1428.9-el5-upd.tz
ash62notes.txt

Let me know how it stands and I'll either finish it up or move it from beta to the release directory.

Thanks Jack.

I'm just in the process of ironing out some bugs in the code that's encountering this issue. Once I've been able to get it working cleanly, I'll get back to you.

Take your time - I don't know how but I think I'll be able to find something to do in the meantime!

I know the feeling!

Testing has thrown up another one. Don't know how I haven't come across this one before, given where we're based, but it looks like the url decoding is also having issues with pound signs (%A3). I'm guessing this is related to the character set in some way. I've got a work around by handling it in code after the fact, but it would be nice to be able to avoid that.

I may have spoken too soon there. Looks like it may be the browser inserting an extra character before a pound sign.

Not sure what to make of this.

The CGIUTL decode in CGIOP_GETPAR seems to work ok, converting %A3 to chr(163).

But for display purposes, the browser is most likely using UTF8, in which case the Pound (£) symbol would be encoded as %C2%A3. Maybe that's the extra character you're seeing?

Yup, that's exactly it. Wasn't looking closely enough before I spoke!

Sorry for the long turn around, the Christmas break has thrown us into a bit of confusion in places!

We're not seeing and issues with the beta of 6.2.1428.9, so I'm happy for that to be made standard.

Thanks Jack, hope the holidays treated you well!