• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 164
  • Last Modified:

Resubmitting form after error

My cgi is in perl on a unix webserver.  I have a special configuration where I allow area publishers to have their own custom areas on their feedback pages then they can submit to my cgi.

I wish to add a feature that re-displays the form when a field is missed or other error occurs so that the user does not need to go back and, depending on their browser/configuration, re-type *all* their information.
Everything is working correctly including re-displaying the custom sections and the previous values of the fields that were entered correctly, radio buttons that were checked, etc.
But I am encountering, I fear, a fatal problem.
When I go to re-submit the form I get the "Document contains no data" error in Netscape and a blank screen in Explorer.

I'm assuming this is related to the data that is displayed in the browser(the new page) being lost when the cgi is again accessed.

I would like to try to find a solution that does not use javascript, cgiwrappers, or that sort.  It needs to be browser independent.  Also, sometimes the data such as in the comments field can be quite long(in characters) so I don't think using the URL to re-submit the values will be effective...

Any help here would be greatly appreciated, if you need to see code, please be specific on the part you wish to see and I will display it(cause the script is rather long :-).
1 Solution
is the second page calling the correct program again (I assume it's the same program)?
If you're using relative addressing of the location for the program to be called (in the <FORM ACTION="....."> part, that might be causing a problem.  Definitely using absolute addressing is the way to go.

If this all works, I can't think of anything else until I see some code.
Your design, as decribed, should work just fine. "Document contains no data" is often due to the called script failing with an error after it prints the headers.

So is it possible that something different about the data from the second submittal is crashing the script? It's very tough to know where to look without seeing it.

Are you trying to validate the REFERER? That would be different the second time and might cause your processing to be different.

To debug, try printing status messages in your script so you can get an idea of how far it's getting and what is failing.

Another idea is to change the METHOD=POST in the form to METHOD=GET, so you can see more easily how the the form values passed to the script the second time differ.

Let us know...
This should work, it must be some small bug in your program, most likely in the form action tag.
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

bgoddenAuthor Commented:
OK, so this might be a further clue, I changed the FORM ACTION directory to the actual absolute path rather than the web root relative path and this time I got:
"Method not implemented
POST to /NextLibrary/WebServer/cgi-bin/process_feedback.cur not supported."
After the second submittal. Does this help anyone? It does certainly look like a bug in the form action.  I wanted to let you guys see this and I will go to work on some of alamo's suggestions to try to weed it out...
As far as the REFERER goes, I use it during the first submittal, then I save it in a hidden value on the re-written page and use it for subsequent submittals, like so:
This is where the REFERER page is processed:
sub get_page
      if ( $FEEDBACK{"refpage"} eq "" )
            $submit_pg = "$ENV{'HTTP_REFERER'}";
            $subdir = substr $submit_pg, 24;
            $rootrel = "/NextLibrary/WebServer/htdocs$subdir";
            $rootrel = '/NextLibrary/WebServer/htdocs$FEEDBACK{"refpage"}';
      return $rootrel;

And then written to the error page as:
<INPUT TYPE="HIDDEN" NAME="refpage" VALUE="$subdir">

Is this value being lost in the process?
The form action in the html your script prints should call your script again... is your script really /NextLibrary/WebServer/cgi-bin/process_feedback.cur?

How does the form tag printed by the script differ from the form tag in the original html that calls it?

As to REFERER - you are actually doing what I had in mind (saving the original REFERER in a hidden field) but the way you are getting teh value in the first place is extremely unreliable... $subdir = substr $submit_pg, 24; without checking that the first 24 characters are what you expect will inevitably lead to problems. Plus, you set $subdir inside a Sub as a global that magically gets included in the html in a different part of the program, another thing that could break easily. If you aren't going to include the entire $rootrel as the hidden field (easier) then at least pass $subdir back and add the path when needed.
bgoddenAuthor Commented:
The form tag I use in the original is "/cgi-bin/process_feedback.cur".  However, following your advice, I think I may have narrow the problem down to something with the array element that holds the $subdir value, on the second submittal, it is not being resolved.  Also, thanks for your other suuggestions, I'll see if I can make this sub more reliable...  Stay tuned, if I debug this soon I'll send the points your way alamo :)
bgoddenAuthor Commented:
Bingo!  Looks like my problems were mainly due to some single-quotes where I needed double-quotes.  I want to accept alamo's comment, but don't see here where to do this, alamo, you may need to re-submit a comment(?)
Congratulations on getting it working!

As you now see, you can't grade me until I post an answer, so here it is. For those who were crazy enough to pay 50 points to read this as a PAQ, read the comments :-)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now