65042 - The website have problem in mozilla ( related to "^" character treat as special character)

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: Other, defect, P3)

Description

[Wan Hing Wah]

BuildID:Mozilla/5.0 (X11; U; Linux 2.2.18pre21 i686; en-US; m18) Gecko/20010107

The website mention have some problem than can't goto another page when
click the linkes. It seem that mozilla treat "^" as special character
and it convert "^" to "%5E" automatically. The webserver is seem
poorly design and can't recognize the character and just return the original
page.
I wonder should the "^" character is treat as  special character in
HTTP Specification and should mozilla provide a option letting the
url won't convert itself?

Comment 1

[Stephan Niemz]

Confirming with build 2001010420 on NT4.

As you said, this is IMHO a problem with the web server, which doesn't
convert the %5E back to the caret (^) sign as it should do.

Changing component to Evangelism accordingly.

Comment 2

[Wan Hing Wah]

From RFC 2068:

          URI            = ( absoluteURI | relativeURI ) [ "#" fragment ]
          absoluteURI    = scheme ":" *( uchar | reserved )
          uchar          = unreserved | escape
          unreserved     = ALPHA | DIGIT | safe | extra | national
          national       = <any OCTET excluding ALPHA, DIGIT,
                           reserved, extra, safe, and unsafe>
and from RFC1738:
national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
                                          ^

clearly the "^" character is legal and belong to unreserved

Although it is because of the lack of feature of the webserver,
from the RFC, the web browser is not necessary to convert "^" to hex code..

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

From RFC 2396, section 2.4.3:

   Other characters are excluded because gateways and other transport
   agents are known to sometimes modify such characters, or they are
   used as delimiters.

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

   Data corresponding to excluded characters must be escaped in order to
   be properly represented within a URI.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

See http://info.internet.isi.edu/in-notes/rfc/files/rfc2396.txt

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Changing back to Evangelism.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Actually, maybe the HTTP spec should win here, since what the URI spec should
also apply to the URLs page authors write within HTML.  Any thoughts?

Comment 7

[Hixie (not reading bugmail)]

RFC 2068 (HTTP/1.1) is obsoleted by RFC 2616 (HTTP/1.1).
RFC 1738 (URLs) is updated by RFC 2396 (URI Generic Syntax).

RFC 2616 (HTTP/1.1) section 3.2.3 URI Comparison says:
# Characters other than those in the "reserved" and "unsafe" sets (see RFC 
# 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

RFC 2396 (URI Generic Syntax) section 2.2 Reserved Characters defines:
#  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
#                "$" | ","

RFC 2396 (URI Generic Syntax) section 2.4.3 Excluded US-ASCII Characters says:
# [These] are disallowed within the URI syntax [...]
#  unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
...and doesn't list an 'unsafe' group.

So ironically, we have found a typo in the HTTP spec. No big surprise there.

However, the above holds up the fact that "^" is not considered to be a valid
character in a URI (a closer look at RFC 2396 also shows this, since "^" appears
in none of the productions that come together to make a URI).

Therefore evangelisation is the correct component.

Comment 8

[Blake Ross]

Reassigning evangelism bugs to [e-mail].

Comment 9

[Bob Clary [:bc] (inactive)]

kat, giving this to you ok?

Comment 10

[Katsuhiko Momoi]

No problem.

Comment 11

[Katsuhiko Momoi]

Setting priority to P3, will investigate.

Comment 12

[Katsuhiko Momoi]

This time really setting the priority.

Comment 13

[Katsuhiko Momoi]

The links are now working. The server seems to be able to decode
%5E correctly back to the "^".
WFM.

Comment 14

[Katsuhiko Momoi]

Moving to Other.