in reply to Re: Is this a bug in HTML::Form::Input or am I doing something wrong?
in thread Is this a bug in HTML::Form::Input or am I doing something wrong?

The input="file" form element in the HTML DOM is read-only from any script. In short, it can be filled out or entered only by a live user, not by a script.

This is not right. You can upload a file from script if you include its correctly encoded contents in the script generated HTTP request.

Ovid's comment regarding filenames in cookies is not related to this. As I understood it he just meant that there is no way to make a browser upload a file whose name has been provided by the server in a cookie.

I haven't tested myself but the problem seems to be that HTML::FORM::click will not automatically read the file from the hardisk and encode it in the HTTP::request object it generates, when submitting a "file" form element (this would require having a way of associating actual files to "file" form elements in HTML::Form. I think this would be a good improvement to this module).

  • Comment on ALERT Re: Is this a bug in HTML::Form::Input or am I doing something wrong?

Replies are listed 'Best First'.
Re: ALERT Re: Is this a bug in HTML::Form::Input or am I doing something wrong?
by Speedy (Monk) on Mar 01, 2002 at 18:54 UTC
    Maybe we are talking at cross-purposes. The scenario I am thinking of is that no script, whether client-browser-based (like JavaScript) or generated in a browser by a script should be able to force a value into the INPUT TYPE=FILE form element AND on its own issue a SUBMIT. I understood that to be the basis of the problem described above: test an existing browser form by using a script to execute it, including the definition of a value from the script for the VALUE element of the INPUT TYPE=FILE form element.

    The W3C HTML 4 specifications are quite explicit about this:
    "A user agent should not send any file that the user has not explicitly asked to be sent. Thus, HTML user agents are expected to confirm any default file names that might be suggested by the value attribute of the INPUT element. Hidden controls must not specify files."
    http://www.w3.org/TR/html401/appendix/notes.html#forms-security

    I also found an email exchange about the issue on the W3C site.

    > And about the security considerations, lets just hope that
    > Java/J/ECMAscript and the DOMs aren't allowing write access to
    > the INPUT TYPE=FILE VALUE attributes and submitting forms by
    > themselves these days.

    The response:
    Luckily Microsoft and Netscape have indeed noticed this, and both have made file input VALUE attributes read-only (you can write to them but it fails silently). This is contrary to the documentation at msdn.microsoft.com though. (Which says value and outerHTML are both read/write.)
    http://lists.w3.org/Archives/Public/www-html/2000Apr/0018.html

    Are you suggesting that a script be able to input the VALUE of the INPUT TYPE=FILE form element without user intervention in a browser file and force a SUBMIT, or do you have some ohter scenario in mind?

    Live in the present
      You are right when you are talking about a browser automatically sending a file without user intervention. Browsers shouldn't do that.

      But, the problem posed here is about having a LWP::UserAgent script submit a form, not about a browser doing it without a user's consent. Submitting a file with a request is perfectly doable with LWP::UserAgent.

      A quick search at google for "upload file script LWP" pointed me to this URL with an example script for doing this.

Re: ALERT Re: Is this a bug in HTML::Form::Input or am I doing something wrong?
by Pug (Monk) on Mar 04, 2002 at 15:30 UTC
    I wrote a module that makes HTML::Form work for file inputs. Can any one see any problems before I submit it to GAAS (The maintainer of this modual.).
    # put this in line #15 # I need to registar the new class. file=>"FileInput", # somewhere else package HTML::Form::FileInput; @HTML::Form::FileInput::ISA=qw(HTML::Form::Input); sub value { my $self=shift; if(@_) { my @temp=($_[0]); return $self::SUPER::value(\@temp); } else { return $self::SUPER::value(@_); } }