https://bugzilla.wikimedia.org/show_bug.cgi?id=17680





--- Comment #14 from Aryeh Gregor <[email protected]>  2009-03-18 
11:23:51 UTC ---
(In reply to comment #12)
> ":" is a reserved character and will be percent-encoded by any browser that
> follows the specification.  See http://tools.ietf.org/html/rfc3986#section-2.2
> and [[Percent-encoding#Types_of_URI_characters]]

If anything, to the contrary, agents are not supposed to encode or decode
colons, specifically because they're reserved:

   URIs that differ in the replacement of a reserved character with its
   corresponding percent-encoded octet are not equivalent.  Percent-
   encoding a reserved character, or decoding a percent-encoded octet
   that corresponds to a reserved character, will change how the URI is
   interpreted by most applications.

If : is indeed considered reserved here, then encoding it would change the
meaning of the URL.  Compare:

   URI producing applications should percent-encode data octets that
   correspond to characters in the reserved set unless these characters
   are specifically allowed by the URI scheme to represent data in that
   component.

Firefox is not a "URI producing application" here -- it's just reproducing the
URI provided by MediaWiki, and so this doesn't apply to it.  It might apply to
MediaWiki (which is why I'm addressing this argument at all), but a) it says
"should", so we can always ignore it if it seems to be safe and makes the URLs
prettier ;), and b) there's the exception "unless these characters are
specifically allowed by the URI scheme to represent data in that component."

If we consult RFC 2616, which defines the http: scheme, we find in sections
3.2.1 and 3.2.2[1] that its production for the path part of the URI is that of
abs_path from RFC 2396.  If we look there, we find[2] that an abs_path can
contain any pchar, with pchar being defined as

      pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","

Therefore I conclude that in "http:" URIs specifically, colons are not reserved
in the path part, and it's perfectly legitimate for us to emit them unencoded,
and for clients to encode and decode them freely (which is what Firefox seems
to do).

[1] http://tools.ietf.org/html/rfc2616#section-3.2.1
[2] http://tools.ietf.org/html/rfc2396 (search for abs_path and follow the
productions)

(In reply to comment #13)
> OK, but what about e.g.,
> http://en.wikipedia.org/w/index.php?title=User_talk:Jidanni&action=history
> Here the colon is also in the query string, but do we ever see it end
> up as %3A in any browser's URL bar, unless we type in in there
> ourselves?

This is not a MediaWiki problem.  Complain to Mozilla.


-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to