REST request with parameters - how to avoid default Content-Transfert-Encoding:quoted-printable ?

Here a workaround. AI suggest me to do my POST request with a groovy script (find bellow the groovy script that I used)

import org.apache.http.impl.client.CloseableHttpClient
import org.apache.http.entity.mime.MultipartEntityBuilder
import org.apache.http.impl.client.HttpClients
import org.apache.http.client.methods.HttpPost
import org.apache.http.util.EntityUtils

CloseableHttpClient httpClient = HttpClients.createDefault()
// Définir l'URL de votre service  
def url = context.expand('${#Global#endpoint.api-interco-url}')+'/interco/lot-bs'
HttpPost post = new HttpPost(url)

// Construire le corps de la requête pour multipart/form-data  
MultipartEntityBuilder builder = MultipartEntityBuilder.create()

// Ajouter des champs de formulaire  
// log.info context.expand('${=testCase.name}')
builder.addTextBody("filename", context.expand('${=testCase.name}') )
// log.info context.expand('${#TestCase#encodedFile}')
builder.addTextBody("content", context.expand('${#TestCase#encodedFile}') )

// Construire l'entité multipart  
def multipartEntity = builder.build()
post.setEntity(multipartEntity)

// Créer les en-têtes de la requête  
// post.setHeader("Content-Type", "multipart/form-data") // laisser le système déterminer le Content-Type
post.setHeader('Authorization', 'Bearer ' + context.expand('${#TestCase#intercoApiToken}'))
post.setHeader('X-Gravitee-Api-Key', context.expand('${#Project#x-gravitee-api-key.header.attribute}'))
post.setHeader('Content-Disposition', 'form-data')
post.setHeader('Content-transfert-encoding', '7bit')
// post.setHeader('Connection','Keep-Alive')

// Envoyer la requête HTTP POST  
def response = httpClient.execute(post)

// Gérer la réponse  
def responseContent = EntityUtils.toString(response.getEntity())

if (response.statusLine.statusCode == 200) {
    log.info "Réponse réussie : ${responseContent}"
} else {
    log.error "http status error code : ${response.statusLine.statusCode}"
    log.error "body content : ${responseContent}"
}

// Fermer le client  
httpClient.close()

Thanks for you different feedbacks. But unfortunately, these do not help me to fix my issue.

I just want to know why I have two different results with the same script execution (soapUI vs ReadyAPI).

My request has two parameters "filename" and "content". The second parameter is filled by a very long string (the result of zip file encoded in Base64).

As I can see, with soapUI, "content" parameter has quoted-printable "Content-Transfer-Encoding" value. Is there any way to avoid this setting done by soapUI ?

With ReadyAPI, the same request editor is different, "content" parameter has no "Content-Transfer-Encoding" value (in Request Raw view there is no break line).

As I said below, it depends of content length.

Under a specific value soapUI keep Content-Transfer-Encoding value to 7bit

Over a specific value soapUI seems to format the content value as Content-Transfer-Encoding set to "quoted-printable" value. It seems that soapUI edit the request as we can see (on request raw) multiple break lines.

An area to explore.

Just happen to see the following thread. If not seen already, please check.

https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

The summary of the question:

how to avoid default Content-Transfert-Encoding:quoted-printable

You can explicitly add the Headers.

In your case, you seem to attach the zip with pdf.

Then try the below headers:

Content-Type: application/zip

Content-Transfert-Encoding: base64

You might have a misunderstanding in how your endpoint expects to receive its data - double check the spec.

If you are to send a file as an attachment (multipart) as you are doing already, then your endpoint should be able to manage all of those Content-Transfer-Encodings, as these are well specified and I can't imagine endpoint developer is not using a standard library.

Which is why I suspect they are expecting it in another way? Perhaps as a single request body, perhaps in a header, perhaps embedded into JSON? In these cases you would do the base64 encoding yourself (groovy-lang.org) and specify the data wherever it really belongs.