-
Notifications
You must be signed in to change notification settings - Fork 706
Description
Confirm this is a Go library issue and not an underlying Cloudflare API issue
- This is an issue with the Go library
Describe the bug
When we use the API to create TXT records, the UI displays a warning that the contents must be surround by double-quotes. However if there are double-quotes inside the string, cloudflare provides no guidance on how to escape them.
This is a feature request. Please add functions to the SDK to properly encode and decode the strings as Cloudflare desires them to be encoded/decoded. Everyone that uses the SDK has to re-invent the wheel and I'm going to guess that 90% of us don't get it right.
Here's a demonstration of the pain-point:
(NOTE: even though the examples use curl, this is a request for the Go SDK.)
We create TXT records like this:
curl "https://api.cloudflare.com/client/v4/zones/REDACTED/dns_records" \
-H "Authorization: Bearer REDACTED" \
-H 'Content-Type: application/json' \
-d '{
"name": "test-record.dnscontrol.org",
"ttl": 3600,
"type": "TXT",
"comment": "this is a comment",
"content": "this is my txt content",
"proxied": false
}'
When we run this CURL command, the UI displays this warning:
"The content field of TXT records must be in quotation marks. Cloudflare may add quotation marks on your behalf, which will not affect how the record works."
If we change the "content" line to:
"content": "\"this is my txt content\"",
The warning disappears.
However, what if the string has a double-quote inside?
"content": "\"inside " example\"",
{
"result": null,
"success": false,
"errors": [
{
"code": 9207,
"message": "Request body is invalid."
}
],
"messages": []
}
Ah! maybe it is RFC 1035 encoded. Will this work?
"content": "\"inside \" example\"",
Nope. That's rejected.
Oh, wait! It's RFC 1035 encoded then JSON encoded.
"content": "\"inside \\\" example\"",
Ah, that worked.
What about backticks?
"content": "\"inside ` example\"",
Ah, that worked too.
What about hex-encoding?
"content": "\"inside \\034 hex-encoded\"",
Ah, that worked.
What about long strings? Do I need to break them into 256-octet chunks?
(this is 270 x "a")
"content": "\"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"",
That worked, but when we retrieve the record we see that Clouldflare has split it into 255-octet chunks. Thus, the API accepts something that it isn't exactly RFC 1035 encoding but it is very close.
In the current state, every user of cloudflare-go must guess the proper encoding and implement it on their own. I'm going to guess that most people implement it incorrectly.
My "ask" is that the SDK add utility functions that encodes and decodes TXT strings as Cloudflare requires so that users of the SDK don't have to keep re-inventing the wheel. A utility function that chunks the string into 255-octet substrings would make a very complete solution.
Possible usage might look like:
// Create a TXT record:
cf := cloudflare.CreateDNSRecordParams{
Name: label,
Type: "TXT",
TTL: ttl,
Content: cloudflare.TXTEncode(cloudflare.TXTChunks(myTxtString)),
}
// Receive a TXT record:
// cr is a cloudflare.DNSRecord
decodedTxt := strings.Join(cloudflare.TXTDecode(cr.Content), "")
To Reproduce
See above.
Code snippets
See above.OS
all
Go version
Go 1.25.3
Library version
v6.2.0