HtmlUnit (3.5.0) is sending a content type of "application/octet-stream" rather than "application/pdf" for PDF files, as form-multipart posts (using BrowserVersion.CHROME).

This is not how modern browsers or other modern HTTP tools appear to behave. E.g., they seem to all send "application/pdf". Obviously a backend can therefore react differently, if it considers this this piece of information.

Example:

Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"; filename="file1.pdf"
   Content-Type: application/octet-stream

   ... contents of file1.pdf ...
   --AaB03x--

... could/should be:

Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"; filename="file1.pdf"
   Content-Type: application/pdf

   ... contents of file1.pdf ...
   --AaB03x--

If it were a JPG or other well-known file type, the Content-Type is correct for binary files (i.e., not application/octet-stream).

This can be adjusted/introduced via:

getBrowserVersion().registerUploadMimeType("pdf", "application/pdf");

However, I think this should be default behaviour (like the real Chrome).

Easy to fix, just needs to be added to BrowserVersion, like the others:

CHROME.registerUploadMimeType("pdf","application/pdf");