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

You are correct, I think my assumption that it is interpreting a semicolon might be in correct. The error message I get when I attempt to use the data (right now using the data is simplying printing the data to output) I get the message "No close tag marker." I'll research what that actually means, but if you have any clue I'd definatley be open to help. Thanks again.

Replies are listed 'Best First'.
Re^3: Semicolons in webforms
by graff (Chancellor) on Dec 31, 2007 at 07:14 UTC
    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.
      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);
      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' );
      The semicolon is located in the tag testproblem:
      <testproblem>ti;me</testproblem>
      As you can see from the parameter list, CGI is interpreting the text after the semicolon as a parameter. Any other thoughts?
        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.)

        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