in reply to Re^2: Semicolons in webforms
in thread Semicolons in webforms

Sounds like derby is likely to be on the right track. The error message is coming from the XML parser, saying that it is reaching an end of string (or end of input) before seeing a closing tag (most likely, it's not seeing </tablefield>). So follow up on the advice below.

Replies are listed 'Best First'.
Re^4: Semicolons in webforms
by dmaranan (Acolyte) on Dec 31, 2007 at 19:12 UTC
    I think I know what is happening but still haven't figured out the solution. First I stripped down the code to use CGI without any of our in house packages. What I discovered is that CGI is interpreting the semicolon as a delimiter of the parameter list sent to the web server. So basically every time the webserver received a semicolon from the client its interpreting it as 'Hey I'm a new parameter!'. I added the line: 
    use CGI qw(-oldstyle_urls);

    [download]
    hoping that it would not see the semicolon as a delimiter, but that didn't work. Here is a dump of the CGI object: 
    $VAR1 = bless( {
                 'strerrortext' => [
                                     'strerror'
                                   ],
                 'strxmltext' => [
                                   '<testproblem>ti'
                                 ],
                 '.parameters' => [
                                    'strxmltext',
                                    'me</testproblem>',
                                    'strerrortext'
                                  ],
                 'me</testproblem>' => [
                                         ''
                                       ],
                 '.charset' => 'ISO-8859-1',
                 '.fieldnames' => {},
                 'escape' => 1
               }, 'CGI' );

    [download]
    The semicolon is located in the tag testproblem: 
     
<testproblem>ti;me</testproblem>

    [download]
    As you can see from the parameter list, CGI is interpreting the text after the semicolon as a parameter. Any other thoughts?
[reply]
[d/l]
[select]
      I'm confused as to at what point CGI comes into this. Earlier, you showed a perl assignment statement representing the (correct!) xml data received by you that you said you were having trouble parsing. Now it sounds like the xml data is being sent as a CGI query to your script by the client (and so is already broken when you initially receive it)? In either case, whoever is forming the CGI request needs to be correctly url-encoding the ; (and semicolons are not necessarily your only problem character.)
      --
      CollegeGear.com - more than just college gear (though, yes, we have college-branded teddy bears)
[reply]

      Like I said, the semicolon is a generally accepted alternative to the ampersand as a parameter separator. You can either

      1. url encode your data before sending it to your cgi script
      2. use something other than CGI to parse your data (bad idea)
      3. subclass CGI and override the parsing method
      4. change the mime type of the submitted stream so CGI will place the data in the POSTDATA field rather than parse it as form and/or GET data

      -derby
[reply]

In Section Seekers of Perl Wisdom