Processes form data and calls provided storage function on file parts.

You can use this together with withTemporaryStore, storeAsLazyByteString or provide your own callback to store uploaded files.

If you need to process uploaded file mime type or file name, do it in the store callback function.

See also foldMultipart.

Example using with small files which can safely be stored in memory.

import qualified Data.ByteString.Lazy as Lazy

handleSmallFiles :: MonadSnap m => [(ByteString, ByteString, Lazy.ByteString)]
handleSmallFiles = handleFormUploads uploadPolicy filePolicy store

  where
    uploadPolicy = defaultUploadPolicy
    filePolicy = setMaximumFileSize (64*1024)
                 $ setMaximumNumberOfFiles 5
                   defaultUploadPolicy
    store partInfo stream = do
       content <- storeAsLazyByteString partInfo stream
       let
         fileName = partFileName partInfo
         fileMime = partContentType partInfo
       in (fileName, fileMime, content)

Given an upload policy and a function to consume uploaded "parts", consume a request body uploaded with Content-type: multipart/form-data.

If setProcessFormInputs is True, then parts with disposition form-data (a form parameter) will be processed and returned as first element of resulting pair. Parts with other disposition will be fed to PartFold handler.

If setProcessFormInputs is False, then parts with any disposition will be fed to PartFold handler and first element of returned pair will be empty. In this case it is important that you limit number of form inputs and sizes of inputs in your PartFold handler to avoid common DOS attacks.

Note: THE REQUEST MUST BE CORRECTLY ENCODED. If the request's Content-type is not "multipart/formdata", this function skips processing using pass.

Most users will opt for the higher-level handleFileUploads, which writes to temporary files, rather than handleMultipart. This function should be chosen, however, if you need to stream uploaded files directly to your own processing function: e.g. to a database or a remote service via RPC.

If the client's upload rate passes below the configured minimum (see setMinimumUploadRate and setMinimumUploadSeconds), this function terminates the connection. This setting is there to protect the server against slowloris-style denial of service attacks.

Exceptions

If the given UploadPolicy stipulates that you wish form inputs to be processed (using setProcessFormInputs), and a form input exceeds the maximum allowable size or the form exceeds maximum number of inputs, this function will throw a PolicyViolationException.

If an uploaded part contains MIME headers longer than a fixed internal threshold (currently 32KB), this function will throw a BadPartException.

Since: 1.0.3.0

A type alias for a function that will process one of the parts of a multipart/form-data HTTP request body with accumulator.

A form parameter name-value pair

Contents of form field of type file

Stores file body in memory as Lazy ByteString.

Store files in a temporary directory, and clean up on function exit.

Files are safe to move until function exists.

If asynchronous exception is thrown during cleanup, temporary files may remain.

uploadsHandler = withTemporaryStore "vartmp" "upload-" $ store -> do
    (inputs, files) <- handleFormUploads defaultUploadpolicy
                                         defaultFileUploadPolicy
                                         (const store)
    saveFiles files

Reads uploaded files into a temporary directory and calls a user handler to process them.

Note: THE REQUEST MUST BE CORRECTLY ENCODED. If the request's Content-type is not "multipart/formdata", this function skips processing using pass.

Given a temporary directory, global and file-specific upload policies, and a user handler, this function consumes a request body uploaded with Content-type: multipart/form-data. Each file is read into the temporary directory, and is then passed to the user handler. After the user handler runs (but before the Response body is streamed to the client), the files are deleted from disk; so if you want to retain or use the uploaded files in the generated response, you need to move or otherwise process them.

The argument passed to the user handler is a tuple:

(PartInfo, Either PolicyViolationException FilePath)

The first half of this tuple is a PartInfo, which contains the information the client browser sent about the given upload part (like filename, content-type, etc). The second half of this tuple is an Either stipulating that either:

1. the file was rejected on a policy basis because of the provided PartUploadPolicy handler
2. the file was accepted and exists at the given path.

Exceptions

If the client's upload rate passes below the configured minimum (see setMinimumUploadRate and setMinimumUploadSeconds), this function terminates the connection. This setting is there to protect the server against slowloris-style denial of service attacks.

If the given UploadPolicy stipulates that you wish form inputs to be placed in the rqParams parameter map (using setProcessFormInputs), and a form input exceeds the maximum allowable size, this function will throw a PolicyViolationException.

If an uploaded part contains MIME headers longer than a fixed internal threshold (currently 32KB), this function will throw a BadPartException.

A variant of foldMultipart accumulating results into a list. Also puts captured FormParams into rqPostParams and rqParams maps.

A type alias for a function that will process one of the parts of a multipart/form-data HTTP request body without usinc accumulator.

PartInfo contains information about a "part" in a request uploaded with Content-type: multipart/form-data.

Represents the disposition type specified via the Content-Disposition header field. See RFC 1806.

Field name associated with this part (i.e., the name specified with <input name="partFieldName" ...).

Name of the uploaded file.

Content type of this part.

Remaining headers associated with this part.

Disposition type of this part. See PartDisposition.

UploadPolicy controls overall policy decisions relating to multipart/form-data uploads, specifically:

• whether to treat parts without filenames as form input (reading them into the rqParams map)
• because form input is read into memory, the maximum size of a form input read in this manner, and the maximum number of form inputs
• the minimum upload rate a client must maintain before we kill the connection; if very low-bitrate uploads were allowed then a Snap server would be vulnerable to a trivial denial-of-service using a "slowloris"-type attack
• the minimum number of seconds which must elapse before we start killing uploads for having too low an upload rate.
• the amount of time we should wait before timing out the connection whenever we receive input from the client.

A reasonable set of defaults for upload policy. The default policy is:

maximum form input size

128kB

maximum number of form inputs

10

minimum upload rate

1kB/s

seconds before rate limiting kicks in

10

inactivity timeout

20 seconds

Does this upload policy stipulate that we want to treat parts without filenames as form input?

Set the upload policy for treating parts without filenames as form input.

Get the maximum size of a form input which will be read into our rqParams map.

Set the maximum size of a form input which will be read into our rqParams map.

Get the maximum size of a form input which will be read into our rqParams map.

Set the maximum size of a form input which will be read into our rqParams map.

Get the minimum rate (in bytes/second) a client must maintain before we kill the connection.

Set the minimum rate (in bytes/second) a client must maintain before we kill the connection.

Get the amount of time which must elapse before we begin enforcing the upload rate minimum

Set the amount of time which must elapse before we begin enforcing the upload rate minimum

Get the "upload timeout". Whenever input is received from the client, the connection timeout is set this many seconds in the future.

Set the upload timeout.

File upload policy, if any policy is violated then PolicyViolationException is thrown

A default FileUploadPolicy

maximum file size

1MB

maximum number of files

10

skip files without name

yes

maximum size of skipped file

0

Maximum size of single uploaded file.

Maximum number of uploaded files.

Skip files with empty file names.

If set, parts without filenames will not be fed to storage function.

HTML5 form data encoding standard states that form input fields of type file, without value set, are encoded same way as if file with empty body, empty file name, and type application/octet-stream was set as value.

You most likely want to use this with zero bytes allowed to avoid storing such fields (see setMaximumSkippedFileSize).

By default files without names are skipped.

Since: 1.0.3.0

Maximum size of file without name which can be skipped.

Ignored if setSkipFilesWithoutNames is False.

If skipped file is larger than this setting then FileUploadException is thrown.

By default maximum file size is 0.

Since: 1.0.3.0

Upload policy can be set on an "general" basis (using UploadPolicy), but handlers can also make policy decisions on individual files/parts uploaded. For each part uploaded, handlers can decide:

• whether to allow the file upload at all
• the maximum size of uploaded files, if allowed

Disallows the file to be uploaded.

Allows the file to be uploaded, with maximum size n in bytes.

All of the exceptions defined in this package inherit from FileUploadException, so if you write

foo `catch` \(e :: FileUploadException) -> ...

you can catch a BadPartException, a PolicyViolationException, etc.

Human-readable error message corresponding to the FileUploadException.

Thrown when a part is invalid in some way (e.g. the headers are too large).

Human-readable error message corresponding to the BadPartException.

Thrown when an UploadPolicy or PartUploadPolicy is violated.

Human-readable error message corresponding to the PolicyViolationException.