## Aurigma Image Uploader 6.5 Dual

# POST Field Reference

- Collapse All Sections

This topic contains the information about POST fields sent by Image Uploader. Use it when writing the server-side upload processing code. You should extract them in the same manner as if they were sent through the standard HTML form. See code samples for more details how to work with them.

In this topic:

- Standard Fields
- Additional Fields
- EXIF And IPTC Fields
- Request Integrity Checking
- Hash Fields

## Standard Fields

Note

Most standard POST fields can be removed from the upload using the RemoveField() method.

The table below contains list of POST fields that are generated and uploaded by Image Uploader.

Name | Type | Description | Upload Conditions
--- | --- | --- | ---
Upload Information
PackageIndex | Integer | Zero-based index of the package (i.e. request) inside the current upload session. Using this field you can recognize the order of the uploaded files if they are sent in different packages. | Uploaded if not removed by the RemoveField() method. This field makes sense only when you upload files in several requests (i.e. the FilesPerOnePackageCount property is not equal to -1)
PackageCount | Integer | A total number of packages in the current upload session. In particular, when FilesPerOnePackageCount is 1, it can be used to get a total number of files uploaded within this upload session.
PackageGuid | GUID | Unique identifier of the current upload session. When the upload is separated into several packages, all of them will have the same GUID. So you can use it to determine whether files are uploaded in the same session (useful for concurrent uploads from several users).
FileCount | Integer | Number of files uploaded in a request. | Uploaded if not removed by the RemoveField() method.
Name | Type | Description | Upload Conditions
Original File Information
SourceFile_N * | File | Original Nth file. | Uploaded when the UploadSourceFile property is true.
FileName_N * | String | Name of the original Nth file. If entire folder is uploaded, this filename includes a folder structure, i.e. relative path of the file (relatively the folder which is being uploaded, including this folder name). It is useful to employ this file to get name of the original file when only resized copy of an image is uploaded (as in the Optimized Upload Sample). | Uploaded if not removed by the RemoveField() method.
SourceFileSize_N * | Integer | Size of the original Nth file in bytes.
SourceFileCreatedDateTime_N * | Time | Creation date of the original Nth file in EXIF-style format: YYYY:MM:DD hh:mm:ss For example, 28th of March, 2:40PM would be looking in the following way: 2005:03:28 14:40:00 | There is a difference between ActiveX and Java versions of Image Uploader related to these fields. See the note below.
SourceFileLastModifiedDateTime_N * | Time | The last modification date of the original Nth file in EXIF-style format: YYYY:MM:DD hh:mm:ss For example, 28th of March, 2:40PM would be looking in the following way: 2005:03:28 14:40:00
SourceFileCreatedDateTimeLocal_N * | Time | The local creation date of the original Nth file in EXIF-style format: YYYY:MM:DD hh:mm:ss For example, 28th of March, 2:40PM would be looking in the following way: 2005:03:28 14:40:00
SourceFileLastModifiedDateTimeLocal_N * | Time | The local last modification date of the original Nth file in EXIF-style format: YYYY:MM:DD hh:mm:ss For example, 28th of March, 2:40PM would be looking in the following way: 2005:03:28 14:40:00
Width_N * | Integer | Width of the original Nth file in pixels if it is a supported image. Otherwise, this field contains 0. | Uploaded if not removed by the RemoveField() method.
Height_N * | Integer | Height of the original Nth file in pixels if it is a supported image. Otherwise, this field contains 0.
HorizontalResolution_N * | Integer | Horizontal resolution of the original Nth file if it is a supported image (measured in DPI - dots per inches). Otherwise, this field contains 0.
VerticalResolution_N * | Integer | Vertical resolution of the original Nth file if it is a supported image (measured in DPI - dots per inches). Otherwise, this field contains 0.
Name | Type | Description | Upload Conditions
Thumbnail Information
ThumbnailX_N ** | File | The Xth thumbnail for the Nth uploaded image. Depending on the UploadFileXCompressionMode_N field value this field contains a thumbnail with one of the following names: OrigFileName.OrigFileExt_ThumbnailX.jpg - for Jpeg and Icon compression modes; OrigFileName.OrigFileExt_CompressedX.zip - for Zip compression mode; OrigFileName.OrigFileExt_SourceX.OrigFileExt - for SourceFile compression mode. | Not uploaded only if a fit mode of the Xth thumbnail is Off and its compression mode is Jpeg.
UploadFileXCompressionMode_N ** | String | The compression mode of the Xth thumbnail of the Nth uploaded file. Possible values are: Jpeg. The Xth thumbnail is JPEG. Zip. The Xth thumbnail is a zip archive. Icon. The Xth thumbnail is an icon. SourceFile. The Xth thumbnail is a copy of the original file.
ThumbnailXFileSize_N ** | Integer | Size of the Xth thumbnail of the Nth uploaded image in bytes.
ThumbnailXWidth_N ** | Integer | Actual width of the Xth thumbnail of the Nth uploaded image in pixels. Depending on the fit mode, this value may differ from the value specified through parameters. This happens because Image Uploader preserves the aspect ratio of the image and not always can use the same dimensions as specified in the thumbnail parameters.
ThumbnailXHeight_N ** | Integer | Actual height of the Xth thumbnail of the Nth uploaded image in pixels. Depending on the fit mode, this value may differ from the value specified through parameters. This happens because Image Uploader preserves the aspect ratio of the image and not always can use the same dimensions as specified in the thumbnail parameters.
ThumbnailXSucceeded_N ** | Boolean | true, if the compression mode of the Xth thumbnail is Jpeg and it is created successfully. Otherwise, false. | Uploaded only if the compression mode of the Xth thumbnail is Jpeg.
Name | Type | Description | Upload Conditions
User Input
Angle_N * | Integer | Rotation angle of Nth upload item (measured in degrees clockwise). This field is changed if the user clicks an arrow icon to rotate an image, or if the automatic EXIF rotation is enabled (see the AllowAutoRotate property for more details). You can use it if you want to rotate images on the server side (e.g. if you upload only source file). Possible values are: 0; 90; 180; 270. | Uploaded if not removed by the RemoveField() method.
Description_N * | String | User-provided description of the Nth upload item. To enable or disable the user to edit the description, use the ShowDescriptions property. Also, it can be edited through the JavaScript via the UploadFileDescription property.
* The N character appended to the field name is a placeholder for an index of this file in the POST request. This index is 1-based. For example, if the user uploads three files, they will get SourceFile_1, SourceFile_2, and SourceFile_3 fields (the same is true for others XXX_N fields). ** Image Uploader can generate unlimited number of thumbnails per each image uploaded to the server. The X character is a placeholder for an index of the thumbnail for the Nth image. X value is the same as you specify when configuring thumbnails through parameters or the UploadThumbnailFitMode property. For example, if you set UploadThumbnail1FitMode and UploadThumbnail2FitMode to some value that differs from Off, and upload three files, the following fields will be available on the server: Thumbnail1_1, Thumbnail2_1, Thumbnail1_2, Thumbnail2_2, Thumbnail1_3, and Thumbnail2_3.

Note

In Java version SourceFileCreatedDateTime_N/SourceFileLastModifiedDateTime_N and SourceFileCreatedDateTimeLocal_N/SourceFileLastModifiedDateTimeLocal_N field pairs have the same values.

Note

Standard POST fields can be renamed using the RenameField() method. Read the Configuring POST Format topic for more details.

## Additional Fields

Image Uploader is able to send not only fields described in the table above, but also custom fields. It can be done in two ways:

- Using the AddField() method. It takes the name of a field you want to extract it on the server and its value. The most convenient place to use this method is the BeforeUpload event.
- Using the AdditionalFormName property. You just add the FORM element somewhere to your code, add elements to it (INPUT, SELECT, TEXTAREA elements are supported), and set its name to the AdditionalFormName property. Image Uploader automatically appends data from this FORM to the request that is sent to the server.

See the Uploading Additional Data with Files topic for more details.

## EXIF And IPTC Fields

In addition to standard and custom fields, Image Uploader can extract EXIF and IPTC data and send it along with other POST fields. To do it, you specify a list of required fields in the ExtractExif and ExtractIptc properties. Before the upload start, Image Uploader tries to extract these fields from files which are being sent. If it succeeds, these fields are appended to the request.

To see a list of supported EXIF and IPTC fields, as well as additional information about this, check out the ExtractExif and ExtractIptc properties reference.

## Request Integrity Checking

The FileCount POST field is sent at the end of the upload request. Thus, it can be used to determine whether the user aborts the upload - if this field is not received the upload is considered as cancelled.

See the Writing Server-Side Upload Code topic for details.

## Hash Fields

If it is necessary to organize robust upload and check the integrity of uploaded files, you can use the HashAlgorithm property. It works in the following way:

1. You see one or several hash algorithms in the HashAlgorithm property.
2. Before the upload begins, Image Uploader calculates the hash value (or several values) according to settings specified on the first step.
3. Base64-encoded hash value is appended to the request.
4. The server side code calculates the hash value using the same algorithm and compares it with the uploaded one.
5. If hash values are the same, the verification is successful. Otherwise, the upload is corrupted.

See the Robust Upload Sample to see it in action.