Telegram: Is there a way for it to ignore all tags?

[jsmith432]

:question: Question

Some messages contain <> in the body (sometimes just an email), and I have not been able to "force" them to go as text. I tried to add "?format=text&overflow=truncate" at the end of the URL, but that doesn't seem to work. Is there a way to bypass this for telegram?

Example test: curl -X POST -d '{"urls":"tgram://mytelegramids?format=text&overflow=truncate","body":"test <myemail@mail.com> body","title":"test title"}' \ -H "Content-Type: application/json" \ "https://apprise.local.mydomain.com/notify/"

Error: 2024-01-01 17:34:40,555 [WARNING] apprise: Failed to send Telegram notification to "mychatid": Bad Request: can't parse entities: Unsupported start tag "myemail@mail.com" at byte offset 17, error=400.

[caronc]

What is feeding your apprise instance? Mailrise, a custom app?

If it's being passed in as html, you'll need to escape them with > and <.

Apprise will handle conversions for you, but only if it knows the source format. The ?fornat= however does control the output . I'll investigate the ?format=text, it may or may not be a bug (comes down to the source comment above).

[jsmith432]

Thanks for your reply. I have two use cases that are affected by this: 1) One that goes through Mailrise (my server emails) [where I first noticed this], (and I posted a question there as well) 2) My stand-alone apprise server (that I call from my code), which I tested with the curl command above.

[caronc]

I'm having a really hard time reproducing this. One issue i had using your example was curl wouldn't work for me unless i defined the -H (Header) information first. Here was my url:

curl -X POST \
    -H "Content-Type: application/json" \
   -d '{"urls":"tgram://redacted","body":"test <myemail@mail.com> body","title":"test title"}' \
   "http://127.0.0.1:8000/notify/"

# Same URL but a bit easier on the eyes since we're doing this from the command line:
curl -X POST \
   -F "urls=tgram://redacted" \
   -F "body=test <myemail@mail.com> body" \
   -F "title=test title" \
   "http://127.0.0.1:8000/notify/"

And the above worked great:

If you're using a docker container, make sure you're using the latest version (although i didn't touch this section of code for a while).

I can make it fail if i tell the Apprise API that i'm passing the content in as "html" because it assumes the data being passed in is already escaped. Hence this fails:

# added format=html
curl -X POST \
   -F "urls=tgram://redacted" \
   -F "body=test <myemail@mail.com> body" \
   -F "title=test title" \
   -F "format=html" \
   "http://127.0.0.1:8000/notify/"

the server produces:

2024-01-27 12:58:06,702 [WARNING] apprise: Failed to send Telegram notification to 778463201: Bad Request: can't parse entities: Unsupported start tag "myemail@mail.com" at byte offset 24, error=400.

But this is intended... if you're telling Apprise the data going in is already properly formatted html, then Apprise has no requirement to assume otherwise. Is it possible your mailrise instance is getting a 'text' formatted email, and passing 'format=html' under the hood (so no conversion by Apprise takes place).

# added format=text (default anyway, so not required to be explicit here)
# But the below works fantastic as well
curl -X POST \
   -F "urls=tgram://redacted" \
   -F "body=test <myemail@mail.com> body" \
   -F "title=test title" \
   -F "format=text" \
   "http://127.0.0.1:8000/notify/"

Maybe @YoRyan can confirm that mailrise only sets the 'format=html' tag if the email it receives is already in an HTML format?

[jsmith432]

Thanks, I appreciate the response. I am running as a docker container. image: caronc/apprise:latest - Apprise Version: 1.7.1

I am still able to reproduce it here:

But this works:

But if I use ?format=text&overflow=truncate using your format, it doesn't work. Is that expected?

[caronc]

I just pushed a new version today, can you update your docker container to v1.7.2 and try again for me? the reason i ask is i did a major refactoring of the overflow (specifically truncate and split). Not saying it will fix your problem, but the code is SOO different from the version you have now, i just want to verify before i troubleshoot this new issue you brought forth :slightly_smiling_face:

[jsmith432]

Same behavior for all three scenarios above on 1.7.2. Additional test: If I only use ?overflow=truncate, it works, but adding format=text breaks it.

[caronc]

hmm... interesting! :thinking:

Thank you for telling me this, i'll need to investigate. Is the message you're sending incredibly large? or even small ones?

[jsmith432]

For testing purposes, I am using the same small body: "test myemail@mail.com body" I do have a need to truncate very large messages, but most of the time, they are small.

[caronc]

The problem is Telegram expects HTML, so ...

<p>body
more body info
</p>

All fine and dandy... but if the message is really, really big > supported upstream characters, the following gets posted:

<p>
body
.... a lot of data and no closing tag due to truncation

The above has an open (p) tag, but nothing closing it. So for this case, the Telegram service will reject the message.

Telegram also supports markdown... how are your results if you add tgram://credentials/?overflow=truncate&format=markdown?

[jsmith432]

I was able to send it using markdown using the short messages. I was having issues with long messages before as it sometimes worked and sometimes it didn't; that is why I went to format text as I didn't have any warning that it wasn't working; I would prefer it to force a message through using all types of formats then not getting a message.

[caronc]

Unfortuantely Apprise isn't an HTML parser, so it can't vet all of the data it's provided. If a split happens in the middle of an HTML message, it has no way of knowing how many nested blocks in the split happened on. It isn't capable of restructuring valid HTML for the first message and then again for the second (as it's heading info would all be in the previous message).

Long story short, if your messages are that big, and you need to use Telegram then switch to ?format=markdown

[jsmith432]

Yes, I understand. That is why I wanted to treat it as text no matter what. Less than 1% of the messages are big, but the problem for me was no warning that a message was attempted to be sent, and it was not sent. I have since built a direct call to telegram APIs from my custom code, sending an email if that fails, and moved away from using Apprise for this specific use case.

[caronc]

Closing off this ticket. I'm sorry to see you go, but if you ever have any more questions/concerns, please do reach out!