Unclear backtick behaviour with escape characters
I have a number of tests that I run, where the body of POST requests must be byte for byte fixed when I run them, since an HMAC is applied across the body, for integrity and webhook authentication.
For this I have been using the single backtick Oneline string body for the POST payloads. But it is not clear to me whether escape characters are allowed here? The documentation does not seem to go into this.
Based on previous experience with other 'verbatim string' constructs, I would expect the following test to pass:
POST https://httpbin.io/post
content-type: text/plain
`Backticks and ...\nbackslashes`
HTTP 200
[Asserts]
jsonpath "$.data" == "Backticks and ...\\nbackslashes"
In other words: the \n does not become a newline character.
But instead it outputs the string:
Backticks and ...
backslashes
Is this intended behaviour?
Hi @CHPmyver
Yes, it's unclear from the doc but it's more complete in the grammar.
- you can't write a "true" newline in a one-string
- if you write `aaa\nbbb`, you're creating a value with a "true" newline
- if you write `aaa\\nbbb`, you're creating a value with the two chars
\andn:
| Hurl format | Valid | Value |
|---|---|---|
`aaa bbb` |
❌ | - |
`aaa\nbbb` |
✅ | aaa bbb |
`aaa\\nbbb` |
✅ | aaa\nbbb |
One-line strings support escaped sequences like:
-
\n=> becomes a new line -
\t=> becomes a tab -
\u{xxx}=> unicode literal with codexxx(for instance,\u{2615}=> ☕️)
I'll take this issue as an opportunity to update the docs.
Note: it you want to be sure that your text body is unaltered, you can use
filebody:
POST https://example.org
content-type: text/plain
file,data.txt;
Thanks for the great answer @jcamiel !