in reply to New CGI Action Call

I'd say a big part of your problem is that you are vastly over-thinking this thing. With code this (unnecessarily) complicated, bugs are inevitable. Just put the values into a hash – probably, the GET/POST parameters are already available as a hash – and get rid of the slew of discrete variables. You could rewrite this whole thing into a half-dozen lines of code, tops, and then you could see the problems. One of the most-basic considerations, of course, is that a browser typically sends only those values that have changed. If you populate a form field with a value and don't change that value, it might not come back in the return stream.

Replies are listed 'Best First'.
Re^2: New CGI Action Call
by Corion (Patriarch) on Mar 26, 2018 at 13:06 UTC
    One of the most-basic considerations, of course, is that a browser typically sends only those values that have changed. If you populate a form field with a value and don't change that value, it might not come back in the return stream.

    I really wonder where in the HTTP / CGI specification this User-Agent behaviour would be specified, since I've never seen nor even heard of this behaviour until now. I do a bit of web and browser automation and don't know of any test suites or code that looks for such cases.

    Can you please point out this weird behaviour either in the specifications or in example cases of browsers and pages on which that happens?

    I will ignore such advice until you show actual code/data.

[reply]
[reply]
Re^2: New CGI Action Call
by Your Mother (Archbishop) on Mar 26, 2018 at 15:21 UTC
    …a browser typically sends only those values that have changed.

    Mostly just putting a pin in this for my own record keeping. But I will say that anyone who posts here that six lines of code, TOPS!, could help and does not then proceed to write those lines of code is the antithesis of what I think this place should be.

[reply]

In Section Seekers of Perl Wisdom