Yesterday, somebody sent me that link in a plain text message:
https://rapidshare.com/#!download%7C856p1%7C2938527513%7CEngNewsBlinkfeedPat...
Roundcube doesn't fully recognize that as a link (only until "download").
Then he sent me the same link in a HTML message, there it is fully being recognized.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 08/07/2013 12:31 AM, Michael Heydekamp wrote:
Yesterday, somebody sent me that link in a plain text message:
https://rapidshare.com/#!download%7C856p1%7C2938527513%7CEngNewsBlinkfeedPat...
Roundcube doesn't fully recognize that as a link (only until "download").
Ticket created, http://trac.roundcube.net/ticket/1489276, I'll try to fix it today. Looks very simple to fix.
Thunderbird act the same way because it is an RFC requirement.
The pipe character, according to RFC 1738 is unsafe in an URL and must be encoded. quoting page 2 of said RFC :
Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters.*Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are*"{", "}",*"|",* "\", "^", "~",
"[", "]", and "`".*
All unsafe characters must always be encoded within a URL.*
so this appears to be a bug in rapidshare.com which doesn't respect RFC rather than a bug in roundcube.
regards,
S.B.
Le 07/08/2013 00:31, Michael Heydekamp a écrit :
Yesterday, somebody sent me that link in a plain text message:
https://rapidshare.com/#!download%7C856p1%7C2938527513%7CEngNewsBlinkfeedPat...
Roundcube doesn't fully recognize that as a link (only until "download").
Then he sent me the same link in a HTML message, there it is fully being recognized.
Cheers,
Am 08.08.2013 11:53, schrieb Sébastien BLAISOT:
Thunderbird act the same way because it is an RFC requirement.
The pipe character, according to RFC 1738 is unsafe in an URL and must be encoded. quoting page 2 of said RFC :
[...]
All unsafe characters must always be encoded within a URL. so this appears to be a bug in rapidshare.com which doesn't respect RFC rather than a bug in roundcube.
But Roundcube DID/DOES detect this is a link in a HTML message. Either it should always or never detect it as a link. I'd prefer always, in the worst case the link doesn't work.
On another issue: Why can't I switch between the HTML and text part in the message I'm just responding to...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Hi,
2013.08.09 19:44, Michael Heydekamp wrote:
Am 08.08.2013 11:53, schrieb Sébastien BLAISOT:
Thunderbird act the same way because it is an RFC requirement.
The pipe character, according to RFC 1738 is unsafe in an URL and must be encoded. quoting page 2 of said RFC :
[...]
All unsafe characters must always be encoded within a URL. so this appears to be a bug in rapidshare.com which doesn't respect RFC rather than a bug in roundcube.
But Roundcube DID/DOES detect this is a link in a HTML message. Either it should always or never detect it as a link. I'd prefer always, in the worst case the link doesn't work.
I guess you're forgetting that in case of an HTML message, it's the sender's user agent that makes that link clickable by adding the appropriate markup. I highly doubt that Roundcube does that on receiver's end.
That said, it seems to me that the RFC quoted has aged and become at least a bit outdated. "Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters" is a week rationale, at least in my opinion. By the way, the RFC also lists "~" as an unsafe character, but I don't think I've ever seen it being encoded, and it's used quite commonly with mod_userdir.
On another issue: Why can't I switch between the HTML and text part in the message I'm just responding to...?
Separate threads for separate issues, please. Unless of course you're fine with other people missing these separate issues. :)
Regards, Rimas
Am 10.08.2013 09:04, schrieb Rimas Kudelis:
2013.08.09 19:44, Michael Heydekamp wrote:
But Roundcube DID/DOES detect this is a link in a HTML message. Either it should always or never detect it as a link. I'd prefer always, in the worst case the link doesn't work.
I guess you're forgetting that in case of an HTML message, it's the sender's user agent that makes that link clickable by adding the appropriate markup. I highly doubt that Roundcube does that on receiver's end.
Of course not. I'm just saying that it SHOULD also parse links in <url></url> tags of HTML messages, if Roundcube would really want to prevent the user from clicking on links with those pretended "unsafe" characters. It doesn't make much sense to apply this measure to text messages only.
I'm NOT saying that Roundcube should care about these those pretended "unsafe" characters at all.
That said, it seems to me that the RFC quoted has aged and become at least a bit outdated.
ACK!
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
A.L.E.C -
Michael Heydekamp -
Rimas Kudelis -
Sébastien BLAISOT