HTTP binding and special characters

I’m using HTTP binding to send telegram messages. Here is my thing:

UID: http:url:d52db6a46a
label: $Telegram
thingTypeUID: http:url
  authMode: BASIC
  ignoreSSLErrors: false
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: GET
  contentType: text/plain
  timeout: 3000
  bufferSize: 2048
  - id: message
    channelTypeUID: http:string
    label: Message
    description: ""
      mode: WRITEONLY
      commandExtension: /sendMessage?chat_id=*********&text=%2$s

I have a string item linked with the message channel. If I assign a value to this string sometimes the telegram is sent, sometimes is not. I’ve made several tests and concluded the following:

  1. If the item only contains letters, numbers, blanks and special characters (,.() the telegram is sent
  2. But if the item contains any accented letter, such as á, or national character, such as ç, the telegram is not sent

I’m able to send telegrams with accented letters using Firefox. What could be be problem with the HTTP binding ?

Thanks, and sincere wishes for a great 2022

Probably those characters are not properly escaped. Is there any reason not to use the telegram binding?

I’ve tried but without success so far. I would prefer to use an existing binding instead of installing a new one.

In Firefox they don’t need to be escaped, so why would it be necessary in the http binding ?

Browsers tend to URL encode stuff.

1 Like

I have this in the logs when using national characters:

2021-12-31 17:00:03.013 [WARN ] [p.internal.http.HttpResponseListener] - Requesting '****/sendMessage?chat_id=*****&text=The%20following%20batteries%20need%20to%20be%20replaced:%20[Interruptor%20Portão%20Garagem:%2016.0%25]' (method='GET', content='null') failed: 400 Bad Request

Looks like http binding is producing escapes for blanks but not for national characters. Could this be automated in the binding ? Or do I need to use a transformation ?

If I modify the item name from Portão to Portao the telegram is sent.

I checked that it behaves like the documentation: the used constructor for the URI escapes “illegal” characters. “Space” is an illegal character and gets escaped. UTF-8 characters are not “illegal” according to the spec and therefore are not escaped. Unfortunately other parts of the chain (in this case the receiving server) are more strict.

Thanks. But it would be great if the binding could call URLEncoder (or similar) to avoid such problems. Shall I open an issue in github ?

URLEncoder is not properly encoding some characters (e.g. it uses + instead of %20 for spaces), so that is not a solution. Yes, an issue on GitHub might be a good idea, so someone can pick it up.

Done #11920

Hmm, this is about the characters that the target external server finds acceptable. One user’s encoding needs are not the same as another’s (and so we have transformations available).

What about encodeURIComponent() ?

That‘s JavaScript, correct? I’m not aware of a Java method with that name, but happy to learn if you know one.

I’ve tried encodeURIComponent() in a JS transformation. It seems to encode blanks and national characters correctly, but unfortunately if I use it in a transformation I get a telegram Urgente%20-%20Inunda%C3%A7%C3%A3o%20Cave instead of Urgente - Inundação Cave

Yes, because the % is an illegal character and therefore encoded. You can see that in the request: the % is replaced by %25.

What are my options then ? Frankly I would prefer that the http binding could take care of it.

Reminder - this about what the target server accepts, not about doing stuff by default in the HTTP binding. User-selectable transformations seem like the correct approach, to suit everyone.

Find out what Firefox did to the URL that you typed in.

Firefox converterted Então ação to Ent\u00e3o a\u00e7\u00e3o

This seems relevant -

The HTTP Thing has an encoding parameter, which might usefully be set to utf-8, but I’ve no idea if that has any impact here.

Thanks but it did not work.

The http binding included in 3.3.0.M1 works but national characters are converted to invalid characters. Shall I revert to SmartHome/J HTTP Binding ? What’s the reason to have several versions in the marketplace ?