»Q« wrote:
In <news:coudnspcid5alfzjnz2dnuu7-smdn...@mozilla.org>,
Ed Mullen <ejevo...@edmullen.net> wrote:
»Q« wrote on 1/21/2015 11:29 PM:
In <news:roqdnqgdwcp7xl3jnz2dnuu7-wudn...@mozilla.org>,
Ed Mullen <ejevo...@edmullen.net> wrote:
»Q« wrote on 1/21/2015 9:00 PM:
In <news:bawdnsvq1od3ayljnz2dnuu7-ywdn...@mozilla.org>,
Ed Mullen <ejevo...@edmullen.net> wrote:
I compose an email to myself with a URL in it ala:
<http://edmullen.net/temp/Stan Rogers - The Witch of the
Westmorland.mp3>
When I send and view the email and hover over the link, the
status bar shows the URL with the spaces removed. If I view the
source the spaces are indeed gone.
Is this new? Normal?
I dunno about new, but according to RFC 3986 (Appendix C) it's
what should happen, i.e., unencoded whitespace should be ignored
when parsing URLs. Whitespace (including line breaks) breaks up
URLs, so removing it is the way to put them back together again.
Able to be defeated?
I expect it's deep in the heart of Gecko and can't be overridden.
IME the quickest way to get the whitespaces encoded is what Ray
suggested, entering the URL in the address bar, then copying it
from the address bar.
Well, I have no recorded history but I do believe this used to
work. I've been putting files on my servers with spaces for years
and sending the URLs to people in emails.
I don't believe an email client should be altering content at all.
It's simply wrong. If I want to send a text stream in a
conversation should the email client alter my content? No! It
should not.
What next? I explicitly type WTFO and SeaMonky changes that to
"What The Furry Over?"
Hey, it's my freaking message.
I'm confused by this. I thought you were having SeaMonkey turn your
message into html (necessarily altering the input) and that the
html it produces had the mangled URLs. If this was happening in
plain text mode, I'm stumped; SeaMonkey shouldn't be altering that.
I was composing the email in HTML mode.
Just tested a plain-text email. With < > brackets around the link
the link shows as clickable and is displayed with spaces. If I look
in the source, the spaces are there. If hover over the link and
check the status bar the spaces are removed!
So SeaMonkey is not modifying the email. It's just that, on encountering
a malformed URI containing spaces, it ignores the spaces - apparently in
conformance with standards, so no problem there.
For sending html, SM has to make a decision about what to do with
the spaces; unencoded spaces are ok in URLs, but not in href
attributes of anchor elements. Removing the spaces implicitly assumes
that they were not unintentional, and encoding them would implicitly
assume that they were intentional. So all SM needs is a mind-reading
module. ;)
When SM receives a plain text message with a URL with spaces, it then
has to make a decision about how to convert that to html for display.
And again the question is whether the spaces were intentional or not.
(Simply putting the unencoded spaces into an anchor's href would make
the link unclickable.)
I think an argument could be made that SM should percent-encode the
spaces in both cases. That would mean that URLs which were
unintentionally broken with whitespace would not get fixed, but they
were broken in the first place. And it would mean that URLs which do
have whitespace would be conveyed correctly.
Stripping whitespace allows long links, wrapped across lines in a
plain-text email, to still work. If the whitespace was encoded to form
the URI, the link wouldn't work. This is also mentioned in RFC 3986
Appendix C, which someone mentioned earlier in the thread.
Something else mentioned earlier was the effect of copying a URI
containing spaces and pasting it, and the pasted text having "%20"s.
That's actually done by the browser on copying - the text it places on
the clipboard is %-encoded - not by the mail client on pasting. After
loading a URI containing spaces, if you copy it from SeaMonkey's (or
Firefox's) address bar and paste into Notepad, it will be %-encoded.
Similarly, if you type a URI containing "%20"s (e.g.
http://www.example.com/uri%20with%20spaces) into the address bar and
load the page, the URI will be displayed with spaces where the "%20"s
were. Displaying them as spaces just makes the address easier for humans
to read; the underlying URIs still contain "%20", not spaces. Other
%-encoded characters are also displayed as the corresponding character
in SeaMonkey's address bar.
Mark.
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
