BE_HTTP_Post mishandles URL encoded parameters when file=@/ is involved.

[ericscheid]

Using BE_HTTP_Post(url, "a=" & GetAsURLencoded("R&D") will send the payload in one blob with header Content-Type: application/x-www-form-urlencoded and the payload as presented in the function call (i.e. preserving the URL encoding.

This encoding is needed since multiple parameters are chained via &. OK, so far so good.

If however a parameter is included of the format file=@/path/file then the payload is instead (sensibly) sent as Content-Type: multipart/form-data, and each piece of form data is sent in it's own part.

However, each of the form fields are also sent in a separate part but this time without the Content-Type: application/x-www-form-urlencoded header for the part. Consequently, the receiver doesn't know the text of that part is urlencoded and handles it as plain text.

The problem with this is any form-data which contains an & would need to be urlencoded to avoid prematurely terminating the parsing into parts, and the %28 then leaks through as if it was in the original text. Sending non-url-encoded text is also a problem if the text contains line-breaks (e.g. html text), as each line would also be treated as a new form-part.

---

This fails: BE_HTTP_Post(url, "name=R&D") ⇒ name = "R", D = ""

This works: BE_HTTP_Post(url, "name=R%28D") ⇒ name = "R&D"

This fails: BE_HTTP_Post(url, "name=R%28D&file=@/file") ⇒ name = "R%28D", file=

This fails: BE_HTTP_Post(url, "name=R&D&file=@/file") ⇒ name = "R", D= "", file=

---

The equivalent in terminal would be something like this: curl url -F name='R&D' -F file='@/file' which works fine as expected.

[nickorr]

Eric,

Thanks for this. This does look like a bug, in that I can't see a reason why it shouldn't be adding the same content type to the parts.

I'll see what we can do to get a fix soon.

Cheers, Nick

[ericscheid]

Also, the documentation page for BE_HTTP_Post should be updated to note that the field parameters should be URL-encoded (rising to must be url-encoded if they include characters such as & or line-breaks).

Most of the time not url-encoding the parameters doesn't cause any problems at all. But when they need to be then things go very wrong.

Of course, the exception would be any param=@/path/file instances (which are instead intercepted and handled differently).