Html 5 Form to Accept Only Txt File Uploads

File input (or "upload") in HTML forms

A class in an HTML document (Spider web page) can incorporate an input chemical element with type="file". This may let the user include i or more files into the course submission. The form is often candy and then that such files are stored onto the disk of the Web server; this is why file input (or file submission) is often called "file upload." File input opens interesting possibilities, but browser back up is still limited and by and large of poor quality even in newest versions. Moreover, users are oftentimes puzzled with information technology, since near people apply file input rather rarely.

This is a legacy document, with many references to outdated browser versions. It does non cover features such every bit the File API or the new features in file upload in HTML5.

This document presents

• the basics, including references to server-side techniques needed, a unproblematic example to examination and notes on how it was intended to work
• notes on browser back up: IE, Netscape, Mozilla, Opera, Safari; users' problems with file input; appearance of the Browse push button and the filename box
• accessibility problems: file input is a challenge to many users
• graphic symbol encoding problems
• suggestions for allowing alternative file submission methods
• some references
• notes on client-side scripting bug
• some technical notes on the specifications and implementations: The enctype aspect;  Submitting several files?;  Setting the default filename;  Getting the original name;  The size attribute;  Setting restrictions on the file size;  Filtering (through a file blazon filter);  The status of RFC 1867.

The basics

The thought backside file input in HTML forms is to let users include entire files from their organization into a form submission. The files could exist text files, image files, or other data. For text files, file input would allow more convenient mechanisms than typing (or cut & pasting) large pieces of text. For binary data, such as images, file input would exist not merely more user-friendly but usually the only practical manner. For more data on the pattern principles of file input, run into RFC 1867, Class-based File Upload in HTML.

Writing an HTML form with a file input field is rather uncomplicated. The difficult affair is really to find or write a server-side script which tin practice something useful when it receives data in such a format. And the really hard thing is to make such processing robust and controlled so that all information is processed properly and so that someone won't e.g. make full your server'south disk space with gigabytes of junk, by ignorance or past malevolence.

You need to know the general basics of writing HTML forms; if you need links to tutorials and references on forms, consult How to write HTML forms. Then, what you need to do in HTML is to write a grade and so that

• the action attribute refers to a server-side script which is capable of handling submissions containing forms or, technically speaking, beingness in multipart/grade-data format; as explained below, don't fifty-fifty dream most using mailto: URLs in action attributes, in this context or otherwise!
• it has the attribute method="post"
• it has the attribute enctype="multipart/grade-data"
• it contains a field
  <input type="file" name="somename" size="chars">
  where
  • somename is a name you assign to the field as you like; the form data set will incorporate the content of the file "under that name", and that proper noun has nothing to do with the filename
  • chars is an integer specifying the desired width, every bit a number of characters, of the filename box to exist displayed; the size aspect is optional, only setting it to some relatively large value (say twoscore) probably helps the user, since the default width of the box in electric current browsers is rather narrow for typical filenames. (Run into notes on the size aspect.)

Minimally, the form needs to incorporate a a submit element too. It may as well contain any other fields you lot like, and explanatory texts, images, etc.

A common trouble with file input in forms is that form data gets sent only but the proper noun of the file is included. The reason is typically that the class chemical element does non contain the attributes mentioned above.

Since browser support to file input is still problematic, consider providing alternative methods of submitting data, too.

Information technology is hopefully evident that what happens in file input is the submission of a copy of the file content. The file on the user's deejay remains intact, and the server-side script cannot change information technology, only the re-create of the information.

Setting upwards a server-side script

As mentioned above, the server-side script (course handler) is the difficult part in creating a possibility for submitting files. There are useful brief notes on that in the FAQ entry, but it is a hard programming issue, and outside the scope of this document of mine. I just wish to emphasize—in add-on to security problems discussed beneath - that what happens to the data subsequently submission is at the hands of the server-side script. It could "upload" it, i.eastward. salve onto the server'south disk under some proper name, but information technology might just too process the data only by extracting some data from it, or ship the data past Email somewhere, or even send information technology to a printer. For case, the WDG HTML Validator provides, as ane culling, a page containing a form for submitting a file to validation.

There are different server-side techniques for processing forms, and then you need to consult documentation applicable to the technique you utilise, which is unremarkably dictated by the characteristics of the server software. In particular, if you use CGI, information technology can be useful to cheque section Programs and Scripts: Perl: File Uploading in CGI Resource Alphabetize. (See too the links under "Related Categories" for scripts in other languages.) You might detect a script suitable for your purposes, or at least ideas for writing your own script. In your own coding using Perl with CGI, yous'll probably benefit from using the CGI.pm module; see especially department Creating a file upload field in its documentation, and my Fool's Guide to CGI.pm. Every bit an another example, if PHP is what you apply, run across section Handling file uploads in PHP Manual. For ASP, see e.thousand. Pure ASP File Upload by Jacob Gilley.

Example

The example below uses my simple sendback script, similar to the one discussed in my document on testing HTML forms but capable of simple treatment of a file field. It simply echoes dorsum the data it gets, just presented and so that your browser will brandish it nicely; for a file field, just 40 first octets (byes) are shown.

The HTML markup is:

        <form action="http://jkorpela.fi/cgi-bin/echo.cgi" enctype="multipart/form-information" method="postal service"> <p> Type some text (if you similar):<br> <input blazon="text" name="textline" size="30"> </p> <p> Please specify a file, or a set of files:<br> <input type="file" proper name="datafile" size="forty"> </p> <div> <input blazon="submit" value="Send"> </div> </form>      

And on your browser, with its current settings, and as possibly affected by my stylesheet, this is what the class looks like

How it was intended to work

RFC 1867 describes, in section iii Suggested implementation, how file input was intended to take place in a typical situation:

3.1 Display of FILE widget

When a[n] INPUT tag of type FILE is encountered, the browser might prove a brandish of (previously selected) file names, and a "Browse" button or choice method. Selecting the "Scan" button would crusade the browser to enter into a file option mode appropriate for the platform. Window-based browsers might popular upwardly a file option window, for instance. In such a file selection dialog, the user would take the selection of replacing a electric current pick, adding a new file selection, etc. Browser implementors might choose let the list of file names be manually edited.

If an ACCEPT attribute is present, the browser might constrain the file patterns prompted for to match those with the corresponding advisable file extensions for the platform.

Upon form submit, the contents of the files would then exist included into the data set sent, as divers by the specification of the multipart/grade-information data type (data format, data encoding).

Browser support to file input

Although most browsers accept supported file input for a long time, the quality of implementations is poor. Therefore users easily get confused with file input.

The following notes on browser support are by and large historical and based on fairly old observations of mine (on Win95, Win98, and WinNT). These notes are followed by more interesting notes users' issues particularly caused past the poor quality of back up on mod browsers.

Internet Explorer

IE 3.0 displays an input box and lets the user type a filename at that place—and it sends the name as part of the class data! Mostly, whatever browser without whatever lawmaking which tries to support input type="file" tin be expected to deport that way. (A browser which does not recognize "file" as a possible value for the blazon attribute can exist expected to ignore that attribute, which means that the default value will exist used, as if blazon="text" had been specified.)

IE 4 has an input box and a "Scan" capability, and it actually sends the file content, but information technology withal allows one file only to be selected. The "Browse" function display is unfiltered, i.e. all files which are ordinarily visible are selectable. There does not seem to be any comeback in this respect in IE v, or IE 6, or IE�7.

Netscape

According to Netscape'southward documentation on file input, support to it exists already in Netscape ii.

Netscape 4 support to file input has a "Browse" capability, too, but the browsing has past default a filter which limits selectability to "HTML files". The user can manually change this, though it is questionable how familiar users are with such things. Merely one file can be specified. There does not seem to be any improvement in this respect in Netscape iv.5. Here is an instance of the user interface:

Mozilla

The higher up-mentioned strange characteristic of Netscape has been fixed in Mozilla, which uses no filter (i.eastward. displays all files); on the other hand it (at least in several versions) gives no user option to switch to a filtered view!

Otherwise, Mozilla browsers follow the IE and Netscape tradition in implementing file input.

Opera

Opera supports file input rather well. It provides a "Scan" card, though the push button for activating it carries the label "...", which might be somewhat disruptive. It lets the user specify several files from the menu:

• Unremarkably when you click on a file, the selection is changed, but...
• if you go on the Ctrl key pressed down while clicking on a file, Opera adds it to the selection, and
• if you keep the Shift central pressed down while clicking on a file, Opera discards the electric current selection and replaces it with a range of files, from the file you lot clicked on to the file you last clicked before that, inclusively.

It isn't perfect though. The Browse window is rather small, and information technology is impossible to pick up several ranges, i.e. you must click on the files individually unless you want to select just i contiguous range. And the box for file names is quite small-scale too, and its size is not affected by the size attribute. See also notes on setting the default filename.

When several files are specified (for i file input field), Opera puts them into a multipart bulletin inside a multipart message.

Safari

The Safari browser is popular in the Mac environment and is now available for Windows besides, every bit a beta version.

I have been told that on Safari, the file input widget has just a scan button, labeled "Choose file…," with no filename field.

Users' problems with file input

On the browsers discussed to a higher place, if the user types a filename direct into the input box, information technology must be the full pathname and it must be typed exactly. If the input is not a name of an existing file (east.g. due to a typo), then the class will be sent as if an empty file had been specified (though with the name given by the user), and no alarm is given. People who encounter file input for the first time might be expected to become very confused, since the filename box appears first and looks like an area where the user should type something.

The user probably often wishes to view the contents of files in the dialog, since it is difficult to select the file on the basis of its name only. On Windows systems, the browsers discussed here seem to use widgets where normal clicking on a file icon selects it, and to open it (in some program) one needs to apply right click and select a suitable action. I judge most users won't find that out without beingness helped. The following screen capture presents the dialogue on IE four (on WinNT) in a situation where the user has right clicked on an icon and an activity menu has popped up and the user is most to select the Open action (which would, in this case, probably open up the .jpg file in a graphics programme or in a new browser window.

In that location'south little you tin do as the author of a form to help users in getting acquainted with such issues. If you think it's useful to refer to instructions for some particular browsing environments, brand information technology articulate what situations (browsers, operating systems) the instructions utilise to.

The technical problems discussed hither are i reason why authors should consider providing alternatives to file input. There'south a department on accessibility problems below, discussing some additional reasons.

The appearance of the Browse button and the filename box

All the browsers mentioned to a higher place use essentially like appearance for the widget used to implement a file input element: a text input box for the filename looks similar to normal text input elements (<input type="text">), and the Browse button resembles submit buttons (thus, is ofttimes grey), and information technology has the text "Browse" or its equivalent in another language.

That text is under the control of the browser, non the author. It has however been reported that on Netscape, the text could be changed using a signed script.

This is somewhat problematic, since information technology does not brand the essential difference between submit and scan buttons visually obvious. Cf. to similar problems with reset buttons.

At that place is no way to guarantee that Browse buttons "expect different" or otherwise strength whatever detail appearance such every bit font face or size. See the document Affecting the presentation of form fields on Web pages for an overview and examples. The Scan button is especially "allowed" to any presentational suggestions; it's typically a "hard-wired" part of the browser'south user interface. In item, on IE, declaring a background color and a text color for input elements in a style sheet affects submit buttons (input type="submit") only not Browse buttons (input blazon="file").

If you call back that "looking different" is of import, you might thus effort suggesting presentational features for submit buttons rather than Browse buttons (i.eastward., for input type="file" elements). However, this would mean that Browse buttons expect like (the default appearance of) submit buttons whereas real submit buttons don't! Then information technology seems that information technology's best to let browsers present Browse and submit buttons their way.

The input box for the filename, on the other hand, seems to be affected by similar factors every bit normal text input boxes. You tin employ various CSS backdrop to the input element, though information technology is far from obvious what they should mean for a file input widget or what they actually cause in each browser.

Historical notation: Since input elements are inline (text-level) elements, you can put text level markup like font around them in HTML. However, such markup is often ignored when rendering form fields For example, <font size="four" face="Courier"><input blazon="file" ...></font> might increment the font size and set the font to Courier. Specifically, this happened on Netscape four simply not on almost other browsers. (As a side effect, on Netscape 4, such a font size alter affected the dimensions of the Scan button but non the font size of the the text "Browse". Notation that if you included a colour aspect there, Netscape  ignored it.)

You could suggest presentational properties in a style sheet too, due east.grand.
<input blazon="file" ... way="color:#f00; background:#ccc">
and these in turn would be ignored east.g. by Netscape four merely applied, to some extent at least, by most other graphic browsers. It is difficult to say how CSS rules should affect the widget, since it is an open question whether e.thou. the text of the Browse button (which is not part of the textual content of the HTML document) should be formatted according to the font properties of the input chemical element. (For instance, IE 4 and Mozilla seem to apply the font-size property but not the font-family property when rendering the button text. IE 6 applies font-family unit too.

The post-obit example demonstrates how your browser treats a file input element where we suggest presentational properties both in HTML and in CSS:

The example has the HTML markup
<b><tt><big><input blazon="file" ...></big></tt></b>
and the following CSS declarations applied to that input element:
color:#630; background:#ffc none; font-size:160%; font-family unit:Courier,monospace; font-weight:assuming
Such suggestions might help in making it clearer to users that there is a special input box. Only try to avoid making it look besides special, since in that location is then the risk of not getting intuitively recognized as an input box at all.

At Quirksmode.org, at that place is a longish article that discusses fairly complex CSS techniques for changing the appearance of file input elements, in a sense: Styling an input type="file". I�would notwithstanding advice against any substantial changes in the appearance. Whatsoever esthetic improvement over browser defaults (in addition to being a matter of taste) has a toll: it makes even the experienced user uncertain of what the widget is.

File input is a challenge to many users

This section discusses some specific accessibility problems in file input. For an overview of what accessibility is and why information technology is important, delight refer to the Guide to Web Accessibility and Pattern for All.

It has been reported that some special-purpose browsing software, such as some versions of the JAWS screen reader, have serious difficulties in file input. This is understandable, since the common implementation in browsers is oriented towards visual interaction.

Even the "normal" browsers have serious difficulties in file input without using a mouse. (In that location are different reasons, including physiological and neurological issues, why the user may demand to piece of work without a mouse or other pointing devide.) In Internet Explorer 6, you can select the Scan push by tabbing, just if you try to use the keyboard to activate it, hitting the Enter fundamental, the browser submits the form instead! Y'all would need to know that striking the space bar (when focused on the Scan button) activates the file pick dialogue. Netscape seven skips over the browse button entirely when tabbing—it cannot be selected without a mouse.

Not surprisingly, on Opera things work reasonably. The user can select the Scan button using the tab fundamental and actuate information technology by pressing the enter cardinal, then select a file for upload from the file organisation; you would utilise the arrow keys move around in the file selection.

On the Lynx text browser, at least on Lynx two.8.4 on Unix, at that place is no Scan button, and at that place is no dialogue for accessing the figurer'south file system. Thus, the user needs to know the verbal path name and syntax to type in the file name for upload, equally is apparently also the example for IE and Netscape.

In that location is likewise the usability problem that the browsing may first from a part of the file arrangement in a manner which is not and then natural to the user. The initial selection might exist e.one thousand. that of the directory where the Spider web browser itself resides! So users demand some acquaintance with such bug before they tin fluently submit files.

More than generally, since file input is relatively rare, users are often non familiar with it. They might not recognize the Browse push, and might accept difficulties in understanding what's going on when they click on it (or neglect to click on it).

Thus, authors should usually include some brusque explanation about the presence of a file input field before the field itself. This tin usually me done in a natural manner, explaining simultaneously what kind and type of file should be submitted.

For case, the explanation could say: "Delight specify, if possible, an epitome file containing your photograph in JPEG format." Such a note may not help much when a user encounters such a field for the first fourth dimension in his life, but it helps him to associate the eventual problems with a concept of file input and to explicate his problems when seeking for assist. And if he has tried to utilize file input earlier, it tells him to stay tuned to something special, and perhaps at this point, before entering the file input field, to access the file system exterior the browser and find the exact path name of the file he wants to submit.

Character encoding problems

The file is submitted every bit such, without code conversions. A apparently text file is submitted without information about character encoding, so the recipient needs to guess the encoding or infer it somehow.

For example, suppose that yous accept a UTF-eight encoded form and that it is used to submit a plainly text file. If the user wrote the file using Notepad, it will (by default) be in windows-1252 encoding, and its content is sent equally such, declared but as text/plain (no charset attribute), fifty-fifty though contents of normal fields are UTF-8 encoded. The server-side form handler has no direct style of knowing what the encoding is, so how tin it meaningfully process the data?

In general, the browser cannot tell the encoding, and so it can neither declare it nor code-convert the data. The reason is that unremarkably used file systems lack indication of the graphic symbol encoding of a plain text file; it just needs to be known.

Thus, if your course is meant for submitting plain text files, your all-time option is probably to enquire users to relieve their text files in UTF-viii encoding with BOM (Byte Order Marking). Y'all can then test server-side that the data, when interpreted every bit UTF-8, starts with BOM.

How to provide alternatives

There are several possible means to let people submit their files even when their browsers do not back up file fields in forms (or the support is of so poor quality that they don't desire to use it).

You could include a TEXTAREA element into the form. This would work particularly for text files in the sense that a user could open his file in an editor and cut & paste the data into the textarea. Naturally, this becomes awkward for big files, but it might still be a skilful idea to take a textarea along with a file input field. Your server side script would need some more lawmaking to handle both.

Y'all could simply include an Email address and encourage people to send their files to that address as attachments. You would need to have some processing for such submissions, but it could be automated using some software similar Procmail. On the other paw, yous might determine that such submissions will be rare, and process them "by hand." Make sure the address is visible on the page itself. Yous could make information technology a mailto: link too, but don't take chances the functionality past some misguided attempt to include a fixed Subject field header! Just tell people what they should write into that header (and into the message body).

Sometimes you lot might consider setting up an FTP server, or using one, so that it has a free upload area. You would so just specify the server and the area, and people could use their favorite FTP clients. Note that for the submission of a large number of files, FTP would be more than comfortable than using a form with a file input field.

Especially for local users, you could merely give a physical address to which people can bring or send their files e.g. on diskettes or CD roms. Make information technology clear to them in advance which media and formats yous can handle that mode.

References

• The office which describes input type="file" in the description of the input element in HTML four.0 Reference by WDG. That certificate is also available eastward.chiliad. as a mirror copy in Denmark. Notation that the document contains, under More information, references to the definition of the input element in HTML specifications.
• Answer to the question How can I permit file uploads to my spider web site? in WDG's Web Authoring FAQ. That certificate too has a mirror re-create in Kingdom of denmark.

See as well notes on RFC 1867.

Notes on customer-side scripting bug

In customer-side scripting, there are some special problems when treatment file input fields. The JavaScript Form FAQ contains answers to such questions:

• FAQ 1154 How can I fix the value of a fileupload form field?
• FAQ 561 How can I excerpt just the file name from a forms file upload field?
• FAQ 780 Can y'all simulate a click on an <input type="file"> button?

See as well notes on filtering higher up as regards to support to outcome attributes for file input.

Technical notes

The HTML 4.01 specification discusses, in section Forms, bug related to file input fields forth with other types of fields. The notes below hopefully help in locating and interpreting the relevant portions.

The enctype aspect

The HTML 4.01 specification defines an enctype attribute for the form element. Its value is generically defined every bit being a "media type", referring to RFC 2045. (That RFC is really just one role of a large set of documents which what media types are. In item, the general description of the media type concept is in RFC 2046.)

A media type, also known every bit content type, Internet media type, or MIME type, defines a data format such equally evidently text (text/plain), GIF epitome (image/gif) or binary data with unspecified internal construction (application/octet-stream).

Only in the context of grade submission, the utilise of a media type as the value of the enctype aspect is meaningful simply if there is a definition of the conversion to exist done. This means the exact fashion of encoding the form data, which is essentially a set of proper noun/value pairs, into a particular information format. The definition must be rigorous, since otherwise it is impossible to process the information in a useful, robust style by calculator programs.

The HTML specification defines ii possible values for enctype:

enctype="awarding/ten-www-form-urlencoded" (the default)

This implies a uncomplicated encoding which presents the fields as proper noun = value strings separated by ampersands (&) and uses some special "escape" mechanisms for characters, such as %28 for the "(" grapheme. It's confusing if people try to read it—it was meant to be processed by programs, not directly read by humans!

enctype="multipart/form-data"

This implies that the form information ready is encoded and then that each form field (more exactly, each "control") is presented in a format suitable for that field, and the data set as a whole is a multipart message containing those presentations every bit its components. This is wasteful for "normal" forms simply advisable, even the only feasible way, for forms containing file fields. The multipart structure means that each file comes in a squeamish "bundle" inside a larger bundle, with a suitable "label" (content blazon information) on the inner "package." This type was originally defined in RFC 1867 simply it is also discussed in RFC 2388 (see notes on the RFCs later).

Browsers may back up other values also, merely are non required to, and it is generally unsafe to employ them. Sometimes people use enctype="text/manifestly", and text/apparently is per se a well-defined media type; merely at that place is no specification of the exact method of encoding a form information set into such a format, and browsers are not required to back up such an aspect—and so anything may happen if you apply information technology.

Normally you lot should non endeavour to re-invent the wheel by writing lawmaking which interprets (decodes) the encoded form data. Instead, telephone call a suitable routine in a subroutine library for the programming language you lot use. It typically decodes the data into a convenient format for yous to procedure in your own code.

It seems that the HTML 4.01 specification contains no explicit requirement that enctype="multipart/form-information" be used if the grade contains a file input field (although information technology explicitly recommends that). Just e.g. IE 4 and Netscape 4 handle form submissions incorrectly if the enctype is defaulted in such a instance: they send the name of the file instead of its content!

Submitting several files?

The HTML 4.01 specification uses the term file select for the "command" (i.e. form field) created by an input blazon="file" element. It specifies file select so that this control type allows the user to select files so that their contents may be submitted with a form. Note the plural "files"—the idea is clearly that one such field should allow the inclusion of several files.

Note that there is nil an writer needs to do, and nothing he can do, to brand a browser permit the option of several files per input field. It depends on the browser whether that is possible.

Yet, as described above, the current browser support is poor: simply some versions of Opera support multi-selection, and these exercise not include the newest versions. And in fact, fifty-fifty if a browser allows users to pick up several files for one input type="file" field, users might non know how they can do that, or how they can do that!

Thus, an author might, equally a workaround, include several input type="file" fields if information technology is desirable that users can include several files into i form submission. Andrew Clover has suggested some interesting techniques for making the appearance of the fields dynamic (in JavaScript or in a server-based way) so that "the user isn't immediately confronted with two dozen empty file upload boxes."

Alternatively, or additionally, an writer might encourage users to employ suitable software like WinZip or WiZ to "zip" several files together. Naturally the server-side script must then be somehow prepared to handle zipped files.

Setting the default filename

The HTML iv.01 specification describes the value attribute for a file input field past saying that browsers (user agents) "may utilise the value of the value attribute as the initial file proper noun." This even so is ordinarily non supported by browsers. The usual explanation is "security reasons." And indeed it would be a security risk if files from the user's deejay were submitted without the user's content. Information technology might be all besides easy to lure some users into submitting some password files! But in fact RFC 1867 duly notifies this trouble; in department 8 Security Considerations it says:

It is of import that a user agent non send whatsoever file that the user has not explicitly asked to be sent. Thus, HTML interpreting agents are expected to confirm any default file names that might be suggested with <INPUT TYPE=file VALUE="yyyy">.

It also mentions (in section 3.4) that the utilize of value "is probably platform dependent" but and so goes on: "It might be useful, however, in sequences of more than one transaction, eastward.thousand., to avoid having the user prompted for the aforementioned file name over and over over again." This isn't specially logical, since how would the name be passed from ane submission to some other? (The mechanism for getting the original file proper noun would be quite unreliable for such purposes.) A more useful application could be this: Assume that your class is for reporting a problem with a item program, say Emacs, and that program uses a configuration file with some specific name, say .emacs, then that yous would very much like to become the user'southward config file for problem analysis. Setting the default name, if supported past the browser, might be an extra convenience to the user.

Thus, they just failed to implement information technology, for no good reason. This isn't a very important flaw, however. The situations where it would make sense to suggest a default file proper noun are rare.

Netscape's old HTML Tag Reference says, in the description of input type="file", that "VALUE= filename specifies the initial value of the input element," merely no actual support to this in Netscape browsers has been reported. Like considerations utilize to the corresponding particular in Microsoft's HTML Elements reference. It additionally messes things upward by describing the intended meaning incorrect: "Sets or retrieves the value of the <INPUT blazon=file>." The description links to a description of the value aspect which says: "The value, a file name, typed by the user into the control. Different other controls, this value is read-merely." This probably relates to using the value property in client-side scripting. And in fact, one tin can read the value in JavaScript (and get the filename entered by the user) merely setting information technology is unsuccessful (without an mistake message); the same applies to Netscape (merely on Opera, even an endeavor to read the value seems to confuse the browser). Annotation that the examples in the to a higher place-mentioned documentation do not incorporate an input type="file" element with a value attribute.

However, support to file input in several versions of Opera handles the value attribute in the post-obit way:

• the value is displayed in the box for file name input
• that value can be edited past the user (as an alternative to using the Browse menu, which changes the content of that box)
• however if the user submits the form so that the initial value has not been changed past the user, there will be a security alert and the user is requested to confirm the submission.
• there does not seem to be any working way to specify a gear up of files in the value attribute.

Such support, however, is absent-minded in Opera 7.54, for some reason.

The following course contains a file input field with value="C:\.emacs". Your browser probably simply ignores that attribute, merely some browsers may use information technology to set up the initial file name:

An example of Opera's security alarm in the situation discussed above:

There was a short-time bug in Opera 6 that created a security hole, which would take permit authors grab users' files without their knowing, i.e. bypassing the dialogue described above.

Getting the original proper noun

RFC 1867 says:

The original local file name may be supplied every bit well, either as a 'filename' parameter either of the 'content-disposition: form-data' header or in the case of multiple files in a 'content-disposition: file' header of the subpart. The client awarding should brand best try to supply the file proper name; if the file name of the client's operating system is not in U.s.a.-ASCII, the file name might exist approximated or encoded using the method of RFC 1522. This is a convenience for those cases where, for example, the uploaded files might contain references to each other, east.chiliad., a TeX file and its .sty auxiliary mode description.

But note that this appears in subsection 3.3 of section 3. Suggested Implementatation. Thus, it is but a recommendation related to 1 possible implementation. Y'all shouldn't count on having a filename included.

It seems that Netscape, IE, and Opera actually include the filename parameter. Nonetheless, only Opera uses the format which seems to be the intended i, every bit deduced from the examples in RFC 1867 (section 6), namely a relative name similar foo.txt, non a full pathname like C:\mydocs\foo.txt. Internet Explorer�7 beta preview behaves similarly, and this has been explained equally a security improvement.

Is the Netscape and IE behavior really incorrect? Well, since most computers have some sort of path proper noun organization for file names, 1 would expect to run into path names in examples if the intent had been that path names are sent. This is consistent with the fact that in society to actually employ the file names for some meaningful purpose (like the one mentioned in RFC 1867: "the uploaded file might incorporate references to each other, e.one thousand., a TeX file and its .sty auxiliary way description," which clearly calls for relative file names). When path names are sent, things go much more than complicated, since their specific syntax (and interpretation) is strongly system-specific, and at that place is even no provision for telling the server what the browser'south file system is. Sending relative names just is also consistent with simple security considerations: avoid sending information about the user's file organisation structure. Note that the security section of RFC 1867 does non mention any problems that might arise from that; this more than or less proves that browsers were not expected to send path names.

The idea of including a filename aspect makes sense of class, and would apply eastward.thou. to a file submission containing a set of HTML documents referring to each other with relative URLs. However, information technology's clear that the processing script would need to strip off the path office of the names (which is in principle risky since C:\mydocs\foo.txt could be a relative filename on many systems!). Moreover, since the submission of several files is currently clumsy at best, the idea would exist of limited usefulness even when it works. (Collections of files that refer to each other past names would be best handled every bit packaged into formats such as awarding/zilch, leaving the file name issue to exist handled by zipping and unzipping programs, which can preserve relative names besides as relative directory structures.)

The size attribute

Although the user is not expected to type the filename(s) into a filename box but use the Browse function, the size of the box matters. When the user selects a file by clicking on it, the browser puts the filename into the filename box, and the name is a full pathname which can be quite long. It may confuse users if they meet the name badly truncated.

Definition of input type="file" in the HTML iii.2 specification said:

Just like [for] blazon=text you lot tin can apply the size aspect to gear up the visible width of this field in average graphic symbol widths.

And about browsers seem to treat the size attribute that manner.

But the HTML 4.01 specification defines the size attribute for an input element as follows:

This attribute tells the user agent the initial width of the control. The width is given in pixels except when blazon aspect has the value "text" or "password". In that case, its value refers to the (integer) number of characters.

This logically implies that for input type="file", the size aspect specifies the width in pixels, not characters. This is probably an oversight, and the gamble of a browser acting literally according it is ignorable.

On the other paw, yous could utilize manner sheets in improver to the size attribute. Using eastward.g. the attribute style="width:25em" could override the size attribute; this currently seems to happen on IE 4 and newer but, simply it should do no harm on browsers which don't support it. However note that although it might seem attractive to utilise style="width:100%", asking the browser use as wide a box as possible, at that place'due south the trouble that at least IE iv puts the Scan push on the same line equally the box. Thus you lot would in effect force horizontal scrolling! Something similar fashion="width:eighty%" would be ameliorate, though it is simply a judge that the box and the button will then commonly fit.

Setting restrictions on the file size

Peculiarly if "file upload" means storing the file on the server'due south disk, it is necessary to consider imposing various restrictions. Information technology would be nasty if some user filled the deejay with gigabytes of junk, by ignorance, or by misclicking, or by malevolence. Run into section Avoiding Deprival of Service Attacks in the documentation of CGI.pm; even if it isn't directly applicable to yous since you utilise other techniques than CGI and Perl, it gives some nutrient for thought in full general.

The server-side course handler can exist coded to practise whatever the programmer wants, and imposing some upper limit is clearly a must. (That is, the code should cheque for the input size, and discard, or otherwise process in a special fashion, submissions exceeding a reasonable limit.)

Whatsoever client-side restrictions, i.e. checks washed by a browser prior to form submission, are unreliable and should exist considered every bit extra comfort to users only—and then that they get a rejection bulletin before.

RFC 1867 says:

If the INPUT tag includes the attribute MAXLENGTH, the user agent should consider its value to stand for the maximum Content-Length (in bytes) which the server will have for transferred files.

Information technology appears that no browser has fifty-fifty tried to implement that, and there'due south no statement about such a feature in HTML specifications. On the contrary, the HTML iii.ii specification says something quite dissimilar:

You can set an upper limit to the length of file names using the maxlength attribute.

Thus, information technology is ameliorate not to use the maxlength aspect, because information technology currently does nil and, worse still, in the future it might exist interpreted in 2 incompatible ways. The HTML four specification takes no position on this: it describes maxlength as defined for input type="text" and input type="password" only.

Filtering (through a file type filter)

The HTML 4.01 specification defines an take aspect for use with input type="file" as follows:

This aspect specifies a comma-separated list of content types that a server processing this form volition handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server.

Thus you could specify, for example, accept="image/gif,image/jpeg", if you are willing to go prototype files in GIF or JPEG format only. Browsers might employ this information to prepare the Browse menu so that only such files are selectable, at least initially. And the HTML 3.ii specification even claims: "Some user agents support the ability to restrict the kinds of files to those matching a comma separated list of MIME content types given with the Accept attribute[;] east.g. accept="prototype/*" restricts files to images." (Notation that "image/*" is not a MIME content type. Obviously the intent is that some "wildcarding" could be practical, but there doesn't seem to be whatever definition nearly that.)

But it seems that browser support is currently nonexistent. No filtering is practical, except on Netscape 4 which initially sets a filter which restricts selectability to HTML documents, no matter what at that place is in an accept attribute! And even if there were back up, you of course couldn't rely on such filtering, for many reasons. If information technology worked, it would be basically for user comfort, non for setting effective restrictions (which must be imposed by the form handler).

Using client-side scripting, yous might aid some users and then that they won't submit information of incorrect type. For case, assume that we wish to have a file input field where a JPEG file must be specified. And nosotros might accept the simplistic view that this means a file name which ends with jpg, and check, in a customer-side script, that the value of the field matches that. Notation that the value is the filename, not the file content. All the same one must be extra careful here. Although the upshot attributes onfocus, onchange and onblur for input type="file" are supported even in earliest JavaScript implementations (from version i.0), at that place are limitations and problems. In particular, onblur seems to be treated strangely, and the obvious thought—associate checking lawmaking with onblur—seems to make Netscape run in an eternal loop. Thus, information technology is probably best to acquaintance the checks with file submission merely. This means using the onsubmit attribute in the form tag. Example:

        <script type="text/javascript" language="JavaScript"> role bank check() {   var ext = document.f.motion-picture show.value;   ext = ext.substring(ext.length-3,ext.length);   ext = ext.toLowerCase();   if(ext != 'jpg') {     warning('You selected a .'+ext+           ' file; please select a .jpg file instead!');     return fake; }   else     return true; } </script>  <form method="mail" name=f enctype="multipart/grade-data" onsubmit="render check();" activeness="http://jkorpela.fi/cgi-bin/echo.cgi"> <p> Delight select a JPEG (.jpg) file to be sent: <br> <input blazon="file" name="pic" size="forty" accept="prototype/jpeg"> <p> Please include a short explanation:<br> <textarea proper name="expl" rows="3" cols="xl" onfocus="bank check();"> </textarea> <p> <input type="submit" value="Send"> </course>      

The status of RFC 1867

The status of the original description of input type="file", namely RFC 1867, Class-based File Upload in HTML, is vague. The HTML 4.01 specification makes only an informative reference to it, and mentions a "work in progress" in this expanse:
ftp://ftp.ietf.org/internet-drafts/draft-masinter-form-data-01.txt
This is all the same outdated data; the URL does non work, and the typhoon has expired. In that location does not seem to be annihilation else even at the level of Net-Drafts to supersede RFC 1867. There is however RFC 2388, Returning Values from Forms: multipart/form-data which might be related to the process. All the same it is not specified to obsolete RFC 1867.

In the HTML 4.01 Specification, the informative references accept been updated and so that a reference is made to RFC 2388, with a note "Refer as well to RFC 1867."

In June 2000, RFC 2854, The 'text/html' Media Type, was issued. It'due south basic purpose was to "to remove HTML from IETF Standards Track" officially, i.e. to brand it explicit that work on HTML specifications has been moved from IETF to W3C. Information technology explicitly obsoletes RFC 1867, together with another HTML related RFCs. Simply note that there is very little in HTML specifications past the W3C that defines what file input really is; they refer to RFC 1867 instead.

RFC 1867 contains much more detailed information nearly "file upload" than HTML specifications. Information technology explains the original idea and how it might be implemented. However, its normative status is vague, and the implementations are withal wanting, so you should by and large not wait browsers to support the idea very well.

---

newtonwask1996.blogspot.com

Source: https://jkorpela.fi/forms/file.html