Server-side validation and cacheable forms

[Yohan Blurp]

Hello everybody. I'm writing a Perl script managing forms submissions
but encounter some difficulty on a step.

1) User submits a form (using POST method). The page being declared as
cacheable with "Cache-Control: max-age=10000".

2) The server-script receives the data, parse and validate them.

2b) If something sounds wrong, it returns a page containg an explicit
error message and a link going to previous cached form (using javascript
history.back).

2c) If all sounds right, it returns a modifiable preview (a web page
containing a formatted output and a pre-filled form in case he wants to
change something). This page is also declared cacheable as the first
one. Here, user can submit the preview as is, or generate a new
modifiable preview.

3) We renew the serial of steps #2. The problem is that, here (after
step #3), if we fall in case #2b, the link doing history.back return to
a non cached page (in spite of "Cache-Control: max-age=10000" in that
page) !

From this constat, I have two questions to ask you :

- Why my first form is well cached (1 -2 -2b -1 works) while next
ones are not (2c -2 -2b -2c doesnt' work : form is not in cache)

- Does my strategy about "what to do when server-side validation find
something wrong ?" is a good one (i.e. provide an history.back(-1)) or
should I go to another direction ?

[Scott Bryce]

Yohan Blurp wrote:

Hello everybody. I'm writing a Perl script managing forms submissions
but encounter some difficulty on a step.

1) User submits a form (using POST method). The page being declared as
cacheable with "Cache-Control: max-age=10000".

2) The server-script receives the data, parse and validate them.

2b) If something sounds wrong, it returns a page containg an explicit
error message and a link going to previous cached form (using javascript
history.back).

2c) If all sounds right, it returns a modifiable preview (a web page
containing a formatted output and a pre-filled form in case he wants to
change something). This page is also declared cacheable as the first
one. Here, user can submit the preview as is, or generate a new
modifiable preview.

3) We renew the serial of steps #2. The problem is that, here (after
step #3), if we fall in case #2b, the link doing history.back return to
a non cached page (in spite of "Cache-Control: max-age=10000" in that
page) !

From this constat, I have two questions to ask you :

- Why my first form is well cached (1 -2 -2b -1 works) while next
ones are not (2c -2 -2b -2c doesnt' work : form is not in cache)

- Does my strategy about "what to do when server-side validation find
something wrong ?" is a good one (i.e. provide an history.back(-1)) or
should I go to another direction ?

Go another direction.

1) The user goes to your form handling CGI script. The script sees that
there is no data posted, so it sends the empty form to the browser.

2) The user submits the form. The CGI script looks for a particular
field (probably a hidden field value) and determines that this is an
initial submission of the form.

2b) If something is wrong, the form is returned to the user with an
error message at the top of the page, and all of his previous data
filled in.

2c) If all sounds right, the form is returned with all of the values
filled in. Here, user can submit the preview as is, or generate a new

modifiable preview.

3) The user submits the form. The CGI script looks for a particular
field (probably a hidden field value) and determines that this is an
subsequent submission of the form. The script also determines which
submit button (preview or post) was clicked. If something is wrong,
return to step 2b. If Preview was clicked, return to 2c. If Post was
clicked, and everything is OK, the data is posted.

history.back(-1) and what is or is not cached are non-issues since the
script is serving the form from scratch every time.

Modules that will make life easier are HTML::Template (to create the
form) and HTML::Entities (to prepare the data to be inserted into the form).

[Yohan Blurp]

In article <jO******************************@comcast.com>,
sb****@scottbryce.com says...

Go another direction.

I'm afraid you're right :-( My main problem is that I have to revamp
this very long script (10,000 lines), which had not any preview in its
first version and worked with this history.back feature, and it will be
not so easy.

Also, the first difficulty I see this morning and after reading of your
post is about this preview. On preview stage (your step 3c) the page
shows the formatted previous and a form to allow to edit-it : I think I
will have not any problem to display this reedition form again in case
of validation error, but it will be harder for the preview itself which
contains image, text, special look n' feel, etc... This knowing I don't
see anything like display_preview() in code ; and more, I suspecte the
displayed imgage doesn't exist anymore on server after preview
display...

I foresee some days and weeks of fun !

[Yohan Blurp]

In article <jO******************************@comcast.com>,
sb****@scottbryce.com says...

Go another direction.

I'm afraid you're right :-( My main problem is that I have to revamp
this very long script (10,000 lines) and it will be
not so easy.

Also, the first difficulty I see this morning and after reading of your
post is about this preview. On preview stage (your step 3c) the page
shows the formatted previous and a form to allow to edit-it : I think I
will have not any problem to display this reedition form again in case
of validation error, but it will be harder for the preview itself which
contains image, text, special look n' feel, etc... This knowing I don't
see anything like display_preview() in code ; and more, I suspecte the
displayed imgage doesn't exist anymore on server after preview
display...

I foresee some days and weeks of fun !