Forum Discussion

kbr's avatar
kbr
New Contributor
10 months ago

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

Hi, I am facing to an issue (with soapUI version 5.6.0). 
My POST REST request have two parameters. One of them is a zip file converted in Base64.
In Request Raw tab You can see a parameter "Content-Transfert-Encoding" with "quoted-printable". The parameter content contains multiple lines may be due to the Content-Transfert-Encoding parameter value.
Expected one line with all the parameter content
How to avoid this default value ?

In a previous topics one member says that soapUI uses the mail api. And explains that if the primary type of this datasource is "text", and :

- If all the bytes in its input stream are US-ASCII, then the encoding is "7bit". 

- If more than half of the bytes are non-US-ASCII, then the encoding is "base64".

- If less than half of the bytes are non-US-ASCII, then the encoding is "quoted-printable".


But how to make sure that more than half of the bytes are non-US-ASCII ?

REST

4 Replies

Sort By
  • JHunt's avatar
    JHunt
    Community Hero
    10 months ago

    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.

    • kbr's avatar
      kbr
      New Contributor
      10 months ago

      Thanks for your reply JHunt.
      What do you mean by "If I send a file as an attachment (multipart)" ?
      I don't use soapUI's attachment functionnality to make my POST request. But I send my file throw a request parameter (name "content") encoded in Base64 (as required our spec).

      I just want to know if it is possible to avoid soapUI such raw (multiple return lines and adding some characters at the end of each of them). I believe that it was related to "Content-Transfer-Encoding:quoted-printable" setting made by soapUI.

       

      Below my service settings with details of base64 request parameter

       

      If my zip file parameter encoded in based64 doesn't contains any pdf file, i don't why (may be due to the parameter length), but soapUI manage it correctly en the parameter Content-Transfert-Encoding : 7bit (see bellow) 

      How to get the same if my zip file contains pdf file ?

       

      PS: To encode in base64 my zip file, i follow your site exemple (see bellow).

      I install ReadyAPI solution, the same request execute properly ğŸ¤”

       

  • nmrao's avatar
    nmrao
    Champion Level 3
    10 months ago

    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

     

  • kbr's avatar
    kbr
    New Contributor
    4 months ago

    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 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.

    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.