I'm seeking clarity on the rules for the search query parameter in the Office 365 Connector - Get Emails (v3)
It strikes me there's a bug here in the connector, as if the developer hasn't implemented escaping properly.
e.g.
subject:"hello world"
However, as may people see, this returns an "unexpected character" warning for the double quotes.
I've seen recommendations to use single quotes, however that simply doesn't work in the intended way.
Looking at the json, double quotes are correctly escaped, so it's not the editor at fault:
{
"type": "OpenApiConnection",
"inputs": {
"parameters": {
"importance": "Any",
"folderPath": "Inbox",
"fetchOnlyUnread": false,
"includeAttachments": false,
"searchQuery": "subject:\"hello world\"",
"top": 25
},
"host": {
"apiId": "/providers/Microsoft.PowerApps/apis/shared_office365",
"connection": "shared_office365",
"operationId": "GetEmailsV3"
}
},
"runAfter": {}
}
So the connector should have no problem seeing the search query has the value
subject:"hello world"
(note rigorous url encoding of space colon and backslash not shown)
However, in practice you get a 400:
{
"status": 400,
"message": "Syntax error: character '\"' is not valid at position 21 in '\"subject:\"Hello world\"\"'.\r\nclientRequestId: a08f1c39-a11f-4a2c-99a3-3b9e8aa4435e\r\nserviceRequestId: a1097faa-735f-4af9-bd34-c289483c17b6",
"error": {
"message": "Syntax error: character '\"' is not valid at position 21 in '\"subject:\"Hello world\"\"'.",
"code": "BadRequest",
"originalMessage": "Syntax error: character '\"' is not valid at position 21 in '\"subject:\"Hello world\"\"'."
},
"source": "office365-ne.azconn-ne-003.p.azurewebsites.net"
}
i.e. it's seeing
"subject:"Hello world""
In order to get this to work one has to escape the " character with a backslash manually in the editor, which results in an doubly-encoded searchQuery:
"searchQuery": "subject:\\\"hello world\\\"",
This strikes me that the search query is not being encoded at all on the way out - instead it is being wrapped with double quotes with no concern for escaping quotes or encoding characters.
I'm concluding the implementation is using a HTTP interface, as putting in a query that breaks URL encoding rules returns a 400 too, indicating no URL encoding is going on at all either.
e.g.
If I use
searchQuery:&
I get the error
{
"status": 400,
"message": "There is an unterminated string literal at position 9 in '\"subject:'.\r\nclientRequestId: e17bdda4-b56e-4bd9-96b9-85a7ed212098\r\nserviceRequestId: 9636df8b-d65b-4e45-aeea-fb48da796a5b",
"error": {
"message": "There is an unterminated string literal at position 9 in '\"subject:'.",
"code": "BadRequest",
"originalMessage": "There is an unterminated string literal at position 9 in '\"subject:'."
},
"source": "office365-ne.azconn-ne-003.p.azurewebsites.net"
}
Which indicates it was probably naievly sent through unencoded as
So:
1. Is this a bug? It looks like a junior developer hasn't been guided properly around encoding.
3. Can you escape it properly in GetEmailsV4 so we're not doing the developer's work please!
