How to retain user input in a form file field ?

[Yohan N. Leder]

Hi. Considering a form containg some input text fields, some checkboxes
and an upload file field. After submission, when I'm back to the form,
all values are retained unless the file field one. Is there a tips to do
this field behavior be the same as the other ?

 

[David Dorward]

Hi. Considering a form containg some input text fields, some checkboxes
and an upload file field. After submission, when I'm back to the form,
all values are retained unless the file field one. Is there a tips to do
this field behavior be the same as the other ?

You can't set it (for security reasons), but you have the file on the
server already. Keep track of where it on the server (give it a
randomly generated filename or something), then give the user the
option to keep or delete the file they've already uploaded (or replace
it, or whatever).

 

[Yohan N. Leder]

You can't set it (for security reasons), but you have the file on the
server already. Keep track of where it on the server (give it a
randomly generated filename or something), then give the user the
option to keep or delete the file they've already uploaded (or replace
it, or whatever).

Understood, but my problem is not exactly to decide what to do with the
already uploaded file (i.e. delete-it or leave-it on server), but to do
that user keep the same file field content when he pushes browser's back
button.

In my concrete case, user submitted a form containing a file field, for
preview. This preview is just on browser, nothing is kept on server
disk. So, from this preview, user can submit for real or be back to edit
and change his input. Actuallu, he has to browse and select a new time
the file to upload, everytime he go back from preview, even if the field
he wants to change is not the file one.

How to workaround this file field behavior (understood it's for security
reason) ?

For example, I've read from url below that an hidden field conatining a
client path could send the file data as does a file field :

http://groups.google.fr/group/comp.lang.javascript/browse_thread/thread/
9baaeeaf7df7a128/f69066e14ee61200?lnk=st&q=%22file+field%22+value&rnum=
42&hl=fr#f69066e14ee61200

Is it true ? If yes, I could manage to do this on onsubmit event using
some javascript code : copy file field value to hidden field and a
visible text one (to do user be aware of the uploaded file), then
destroy the file field element. Thus, when user be back from preview,
hidden and visible text fields keep their values. Of course, it's just
an idea and there's certainly a lot of drawback (for example, what if
user want to browse again knowing file field has been destroyed).

Do you think about another work around ?

 

[Jukka K. Korpela]

In my concrete case, user submitted a form containing a file field,
for preview. This preview is just on browser, nothing is kept on
server disk. So, from this preview, user can submit for real or be
back to edit and change his input.

I'm afraid I have bad news. Internet Explorer 7 beta does not let you do
such things. For security reasons, they say, the filename is not even
available to (client-side scripting in) the browser, still less sent to the
server. Unless you can persuade them to change this (I tried a little, in
the microsoft.* newsgroup for IE discussions, in vain), you and many other
people will have to find out something different.

Actuallu, he has to browse and
select a new time the file to upload, everytime he go back from
preview, even if the field he wants to change is not the file one.

Wouldn't the solution be to store the data (contents of the file) on the
server and insert an identifier for it into the form sent back to the user?
The robust way of retaining user input is that the form handler sends a
response page that contains the user input as prefilled values of fields.
For a file, you would have to play with indirection, i.e. an identifier such
as a generated file name (on the server).

 

[Yohan N. Leder]

Wouldn't the solution be to store the data (contents of the file) on the
server and insert an identifier for it into the form sent back to the user?

Or insert base64 content in an hidden field. But, however, nobody can
lock user to push the browser's back button, or close suddenly his
browser (for this, I don't like to keep temporary file on server disk)

The robust way of retaining user input is that the form handler sends a
response page that contains the user input as prefilled values of fields.
For a file, you would have to play with indirection, i.e. an identifier such
as a generated file name (on the server).

Well, so, the idea is always to go forward and avoid previous step
caching ?

 

[David Dorward]

Or insert base64 content in an hidden field. But, however, nobody can
lock user to push the browser's back button,

If the user wants to return to the previous step and throw away some data -
that is their choice.

or close suddenly his browser

Likewise if they want to give up.

(for this, I don't like to keep temporary file on server disk)

Periodically discard old temporary files instead.

 

[Yohan N. Leder]

Periodically discard old temporary files instead.

Even if better for client side, it sounds like less smart on server one.
Well, do you confirm or not that an hidden field containing a client
path will send data as a file field does ?

 

[David Dorward]

Even if better for client side, it sounds like less smart on server one.
Well, do you confirm or not that an hidden field containing a client
path will send data as a file field does ?

Generate a session token (a long string of random characters) to identify
the user.

 

[Jukka K. Korpela]

Even if better for client side, it sounds like less smart on server
one.

In HTML forms, the server needs to be smart, since HTML forms are so
stupid^H^H^H^H^H^Hsimple by design.

Well, do you confirm or not that an hidden field containing a
client path will send data as a file field does ?

What are you talking about? Weren't you explained that such ideas don't
work? Surely a hidden field containing a string (that you call "client
path") will send exactly that string.

If you included the _content_ of the submitted file (suitably encoded) into
a hidden field, you could expect to get it back (as encoded, so you would
first need to decode it). But this would be rather pointless, since it is
simpler and surely more efficient to store data on the server and retain an
_identifier_ for it.

 

[Yohan N. Leder]

Generate a session token (a long string of random characters) to identify
the user.

OK, but it doesn't reply to my question. Do you confirm or not that an
hidden field containing a client path will send data as a file field
does ?

 

[Yohan N. Leder]

What are you talking about? Weren't you explained that such ideas don't
work? Surely a hidden field containing a string (that you call "client
path") will send exactly that string.

Well, it is my reply. This info came from a thread found on google :
I've given, the url at the beginning (or close) of the thread.

 

[David Dorward]

OK, but it doesn't reply to my question. Do you confirm or not that an
hidden field containing a client path will send data as a file field
does ?

It won't. It would be a security hazard if it did. But you already have the
file on the server, so it would be a waste of bandwidth transferring all
that data again - which is why you generate a very-hard-to-guess identifier
instead.