Closed
Bug 576536
Opened 16 years ago
Closed 16 years ago
IE understands %2E in a DNS, but FireFox does not.
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
DUPLICATE
of bug 309671
People
(Reporter: gperreault, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 ( .NET CLR 3.0.4506.2152)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 ( .NET CLR 3.0.4506.2152)
IE understands %2E in a DNS, but FireFox does not. Should it? This particular link sample is generated by SharePoint. It replaces all dots with %2E. It is annoying to not be able to access these links without first editing the %2E in the DNS and put back dots in their place.
Reproducible: Always
Steps to Reproduce:
1. Try: http://microsoft.com
that will work.
2. Try: http://microsoft%2Ecom
That will fail and the URL will be changed to:
http://www.microsoft.com.com/
Actual Results:
Server Not Found
Expected Results:
Web page
If it is not a "standard" to replace %2E in DNS by dots, could it be an "option"? Like I said, it is really annoying.
Comment 1•16 years ago
|
||
http://www.ietf.org/rfc/rfc1738.txt
> Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
> reserved characters used for their reserved purposes may be used
> unencoded within a URL.
> On the other hand, characters that are not required to be encoded
> (including alphanumerics) may be encoded within the scheme-specific
> part of a URL, as long as they are not being used for a reserved
> purpose.
>3.1. Common Internet Scheme Syntax
...
>//<user>:<password>@<host>:<port>/<url-path>
...
>host
> The fully qualified domain name of a network host, or its IP
> address as a set of four decimal digit groups separated by
> ".". Fully qualified domain names take the form as described
> in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
> [5]: a sequence of domain labels separated by ".", each domain
> label starting and ending with an alphanumerical character and
> possibly also containing "-" characters. The rightmost domain
> label will never start with a digit, though, which
> syntactically distinguishes all domain names from the IP
> addresses.
looks like invalid to me. You should report this bug in their software to MS.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
| Reporter | ||
Comment 2•16 years ago
|
||
If that is the case, why does FireFox transform the URL from:
http://microsoft%2Ecom
into:
http://www.microsoft.com.com/
Should it not leave it alone? Maybe there is another RFC that states that %2E, including those in the DNS, should be transformed into dots. Why else would FireFox already do that? It just seems that it should do it before using the URL, not after. Or it should not do it at all.
Comment 3•16 years ago
|
||
> Why else would FireFox already do that?
That transformation is part of the "invalid URI; try to fix it up" process, which does all sorts of odd thing.
In an case, this bug is a duplicate. There was in fact a newer RFC that supersedes RFC 1738.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Comment 4•16 years ago
|
||
bah, i always find only the out of date RFCs :-(
But I didn't expect that sharepoint is an external application that calls the browser.
I thought that it's a "web application" and URL fixing wouldn't be done for such links.
Reporter: Do you get this links with the escaped dot from an external application or inside a website ?
| Reporter | ||
Comment 5•16 years ago
|
||
SharePoint is a M$ Windows application. The function that is does poorly is to generate an text version of a link that it puts on the clipboard. Someone suggested that maybe the SharePoint admins might be able to do something on their end.
I agree that the particular annoyance I have at the moment is with SharePoint. I was just hoping it could be fixed in FireFox since M$ IE handles that mistake. But since they created the mistake in the first place, it is probably no surprise that they fixed it in the wrong place (IE), instead of where the mistake originated from (SharePoint). Typical of them!
You need to log in
before you can comment on or make changes to this bug.
Description
•