The following header fields are automatically set:

   "Connection"
   "Cache-Control"
   "Content-Type"
   "Content-Length"
   "Authorization"

However you might want to use this parameter to explicitly set e.g. User-Agent or non-standard header fields that are required for your particular endpoint. For example by overriding User-Agent you can make the upload operation look to the endpoint as if it comes from a browser.

Example:

    <additionalHeaders>
        <!-- impersonate Safari browser on iPad  -->
        <User-Agent>Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405</User-Agent>
        <!--  just an example of a really weird header field  -->
        <From>joe@mycorp.com</From>
    </additionalHeaders>

If the URL is specified with a hostname as opposed to an IP address then a name lookup needs to be performed. This is not included in the connect timeout. The connect timeout is the time it takes to establish the tcp connection, nothing else. The timeout for name resolution (DNS lookup) is platform dependent.

Example

   <extraFields>
       <field1>value1</field1>
       <field2>value2</field2>
       ...
   </extraFields>

Typical use cases: Extra fields are often used to provide information about the uploader such as a name or an e-mail address. Or they can convey additional information about where the server should put the files, such as a destination folder or similar.

NB: Don't set the filename field here. Posting content for filename is handled automatically.

Files larger than 100 MBytes will see a log entry for every one percent uploaded. For files less this size there will be proportionally less log entries.

This parameter will only turn off the actual progress logging not the logging at the beginning and end of the file upload operation.

You may have to increase this parameter if the endpoint takes a long time to process the uploaded data.

The plugin derives which protocol to use from this value.

Examples:

  https://solar.mycompany.com/upload
  http://pluto.vanilla.org/acceptfiles

Example:

    <uploadFiles>
        <uploadFile>
            <file>${project.build.directory}/myfile.jar</file>
        </uploadFile>
        <uploadFile>
            <formFieldName>file2</formFieldName>
            <file>c://mydir/whatsup.dat</file>
            <hintFilename>whatsup.xls</hintFilename>
        </uploadFile>
    </uploadFiles>

There must be at least one uploadFile element.

The elements of an uploadFile are as follows:

• file. File to upload.
  Type: java.io.File, Required: Yes
• 
  
• hintFilename. Hint given to the server as to what the server should name the file. If this value is not set explicitly it will be derived from the filename of the file element.
  Type: String, Required: No
• 
  
• mimeType. This is the http Content-Type used when the file is uploaded. If not given explicitly here it will be derived from the file name extension using Java's URLConnection.guessContentTypeFromName() method and if this fails then application/octet-stream will be used.
  Type: String, Required: No
• 
  
• formFieldName. The form field name to POST the file to. This value depends entirely on the server you're uploading to. Typically such a field is named "file". There's no requirement that the value is unique among the files to be uploaded. If you don't know what this value should be then leave it out. If no value is supplied then the plugin will automatically supply the names file, file2, file3,... and so on, to those <uploadFile> elements where no value was supplied.
  Type: String, Required: No

If the value is false then the server's certificate is not validated in any way. This may be useful when working with endpoints that use a self-signed certificate.