I need to send an URL that contains thespecial character # through Telegram API post request.
I'm currently use HTML as parse mode.
The message to send is something like:
<a href='www.example.com/#/otherparams'>inline link example</a>
But when I send message the substring of the URL from the # to the end is automatically deleted.
I try to encode the # with related ASCII code %23 and the message is sent correctly, but the when I click on the link the URL doesn't works. I think there isn't a resolution of %23. If I manually replace the ASCII code in the URL bar of the browser with # works.
I obviously try to escape the char # with backslash, but the problem still persists.
On the docs I can't find nothing.
This is an example of script that I'm using, written in Python.
The problem is only #, if I change the message with an URL that doesn't contain #, the script works.
import requests
msg="<a href='www.example.com/#/otherparams'>inline link example</a>"
requests.post("https://api.telegram.org/bot" + token + "/sendMessage" + "?chat_id=" + chat_id + "&parseMode=html&text=" + msg)
Related
Trying to understand why pasting the first link works but not the second one.
Breakdown of the URL, for a clearer view:
Encoded version: [works]
http%3A%2F%2FsomeSite.com
%2FDownload.ashx
%3Frequest
%3DIL7zxW6ETqiYU6cThSNKL8MpY
%252bCRIVFZAVhd8DYPG85C1Uhdd
%252f2hqqmoObeNmuS3dg4bDgGBb0kUUxGZhej89kTaLBHBXS
%252bq3tlaEk2uMEcbWlUZzZQs00sirwZ2IvAvoSpU7HC3N1FaYSNciQ4iHNNmTU
%252f6uMypNlPOJ6enlbZ1OrrYODkaMRdRfGKEba
%252brusdryM4gp
%252bopi1a0gNuMQVCtj
%252bAvDcgXGOcZPNhPAnE
%253d&version=Ma88r6Z6t2JQcnVhVXgp0A%3D%3D
Decoded version: [doesn't work]
http://someSite.com
/Download.ashx
?request=
IL7zxW6ETqiYU6cThSNKL8MpY
+CRIVFZAVhd8DYPG85C1Uhdd
/2hqqmoObeNmuS3dg4bDgGBb0kUUxGZhej89kTaLBHBXS
+q3tlaEk2uMEcbWlUZzZQs00sirwZ2IvAvoSpU7HC3N1FaYSNciQ4iHNNmTU
/6uMypNlPOJ6enlbZ1OrrYODkaMRdRfGKEba
+rusdryM4gp
+opi1a0gNuMQVCtj
+AvDcgXGOcZPNhPAnE
=&version=Ma88r6Z6t2JQcnVhVXgp0A==
If I paste the first link in the browser - it works. A file download automatically starts.
If I paste the second link in the browser - page says Bad request.
Can anyone clarify it for me why the second one doesn't work?
Quoting the URLencodetag:
To “URL encode” or “percent encode” text means to encode it for use in a URL. Some characters are not valid when used as-is in URLs, and so much be URL-encoded (percent-encoded) when appearing in URLs.
The encoding was used for a reason, here because the base64 values for the request and version parameters contains +, / and = which have their own meaning in URLs and therefore need to be URL-encoded.
i am using firebase dynamic link to shorten my url but on doing so its gives the response of "warningCode": "UNRECOGNIZED_PARAM" as my url contails '#' sign. and its generates the short url of the data before # and ignores the data after #.
My url is mentioned below:-
"https://example.page.link/?link=https://example.com/#/xyz/pqr/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.aTExSk5la3ZMUVUwTGU2ZTA3OThrdFRkVXE3ZThUZ0lZNzdpckVDcDhSRkIrZHBSUDl0ZFU0SlJOUkYwN0hwYXp2aUF4RlVZZjlTdGYzRnVJWlZpTlRxUDJvWlhyWVhCemJHa1VDc053Sm0vRmlYZlh4bGRb2xjcHM1RmhhdktkY2dRa1RhUlFPQjIya0Z2bWJSeEQ4YVFhY2FtSlJUOGFVMVR5ZUhOZm54Zz09.dhDJWIz9gqmnbhRhkwgZolwNZ8ba4CCjDEYlefkilPc"
i am calling api:-
https://firebasedynamiclinks.googleapis.com/v1/shortLinks?key=my-key
encode the url first before passing it to the api end point
I'm generating an e-mail in my website's controller with a link to my website:
"http://" & Request.Url.Authority & "/some-page"
This works when I tested it on my local machine (returns localhost:12345) and in production (returns www.company.com) but 1 person got this as a result:
http://www.company..com/some-page
As you can see there are 2 .. in the domain name. I can't reproduce this error, how is this possible?
Edit: a bit more information
The type of email I'm sending is a plain text email (no HTML or RTF)
The webserver logs show www.company.com as the domain when the problematic request was made
I only received a partial screenshot of the email. I think the email client is Outlook but I see no reason why Outlook would have misinterpreted the link.
It's certainly possible that this person (or malware) has edited the content of this email.
This is actually a problem with how the email is being encoded, see this answer: https://stackoverflow.com/a/6603002/186288. In summary, you should change the encoding to UTF8 to force base-64 encoding of the email, otherwise some email clients can misinterpret the default Content-Transfer-Encoding: Quoted-Printable; encoding and add in extra "."s in URLs that happen to hit a wrap point.
To do this, add this line before you send the email:
mail.BodyEncoding = System.Text.Encoding.UTF8;
I should have tried this sooner with a simple example:
Module Module1
Sub Main()
Dim SomeAddress As New Uri("http://www.example..com/test")
Console.WriteLine(SomeAddress.Authority)
End Sub
End Module
This will throw an exception in the constructor:
System.UriFormatException - Invalid URI: The hostname could not be
parsed
So the customer couldn't have received such an email from my code without editing it.
Why are you using Request.Url.Authority? I suggest you avoid to use it, and use Request.Url.Host. It's better to use Request.Url.Host or Uri class constructor, when consturcting incorrect URI it will throw exception and you can either log it or show error.
Anyway it's hard to predict why one user have got www.company..com Anyway your code with Request.Url.Authority concatenation can not produce it. So maybe error is in other location.
I have an encrypted query string passed from another page, it reads something like "/se73j+sef" but after receiving it, the '+' sign got omitted and became "/se73j sef". Is this normal? Please kindly advice. Thanks.
Is this normal?
Yes, perfectly normal. + is a special character in an url. It means space (0x20 ASCII character). If you want to represent the + sign you will have to url encode it:
/se73j%2Bsef
To url encode a string in .NET you could use the UrlEncode method. Or depending on how you are building the url there are certainly better ways.
In some javascript, I have:
var url = "find.aspx?" + "location=" + encodeURIComponent( address );
alert( url );
location.href = url;
where the value of address is the string "Seattle, WA".
In the alert I see
find.aspx?Seattle%2C%20WA
as I expect.
But on the server side, when I look at Request.Url, the relevant substring I see is
find.aspx?Seattle, WA
And in the Firefox url window I see
find.aspx?location=Seattle%2C WA
So I'm getting three different representations whereas I would expect that in all three places I should see what I see in the alert. My expectation is that the url I assign to location.href should show up as-is in the browser url window, and should be passed as-is to the server in Request.Url (and I would need to decode the values on the server before using them). What's happening?
Firefox converts certain encoded characters into their literal forms as a way to be friendly to users. It will also convert spaces typed into the address bar into %20 for the server.
Update: The reason Firefox doesn't display the comma unencoded is because commas are allowed in URLs, but spaces are not, so it knows that a space is going to be unambiguously interpreted, whereas the pre-encoded comma is different from a non-encoded comma to some servers. see: Can I use commas in a URL?
ASP is probably trying to help you out by auto-un-encoding the string for you.
Update: It looks like ASP.NET unencodes Request.Url for you by default, as mentioned here: QueryString malformed after URLDecode They also mention that you can use HttpRequest.Url.Query to access the un-decoded version.
The alert is the only thing not doing any "magic" for you.
For the alert, you are doing the encoding yourself. Perhaps it looks the same as on the server-side if you removed encodeURIComponent.
On the server side, ASP.NET will always show you the unencoded form. This is to make it easier to directly map to files that also have text that needed to be (un)encoded.
Note that you can replace every letter for its UTF8 representation in URL Encoding. It will still be the same URL. I.e., type the following in the browser window and it will still work: %66%59%6E%64.aspx?location=Seattle%2C%20WA. To only encode the necessary chars, use UrlEncode on the server side if you create a link yourself.
URL encoding can become fairly tricky. You ask to explain it. To know the correct escape of a certain character, you need to know how that character looks in UTF8. The hexadecimal value of the UTF-8 bytes then become the %XX%YY value of your letter. Sometimes it's one %XX, but it can be up to six byte sequences in total (some Chinese characters for instance).
URL Encoding works one way only. Never double-encode or double-unencode. This is prohibited by the specification. Also, because you can encode any character, it is not always possible (as you found out) to do roundtrip encoding/unencoding. If you unencode and re-encode again, it is well possible that the resulting string is different, but syntactically the same.
In HTML, URL Encoding is sometimes interspersed with HTML Encoding. I.e., the ampersand is valid in HTML, but not in HTML. find.aspx?city=A&name=B becomes find.aspx?city=A&name=B in and HTML URL. However, browsers are lenient and will accept wrongly HTML-encoded strings.
Finally, a not on the browser: if you type in a space in a link, even inside an <a> tag, it will escape the space (or other character) for you. Likewise, it will nowadays show the odd characters (é, ï etc) in the address bar, but when it sends it over HTTP, the browser will correctly do the encoding for you.
Update: about anwering your question of needing a "definitive" reference or proof.
While I couldn't find any on the internet, I decided to look for it myself using Reflector. Going through the methods that set, for instance, the HttpRequest.QueryString, you quickly encounter the private method HttpRequest.FillInQueryStringCollection which then calls HttpValueCollection.FillfromEncodedBytes. Somewhat near the end of that method, HttpUtility.UrlDecode is called for the values. Conclusion: do not call it yourself, to prevent double decoding.
You can see this for yourself when you download Reflector and disassemble the .NET libs of System.Web.
For your example you can change this line
var url = "find.aspx?" + "location=" + encodeURIComponent( address );
to
var url = "find.aspx?" + "location=" + address;
and see the address as it is. Bu if address variable contains any '&' character your variable will be corrupt. So you are using encodeURIComponent to encode these things url.
On the Server side all these encoded strings are decoded back. It means encodeURIComponent is just for sending the address variable (whether it contains & character or not) to server side correctly.