Closed Bug 243168 Opened 20 years ago Closed 19 years ago

in relative urls character "+" is not url-encoded, even when href=".." correctly used "%2B"

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED EXPIRED

People

(Reporter: bugzilla, Assigned: darin.moz)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

if a link <a href=".:"></a> contains a plus sign "+", it must be url-encoded,
that is: replaced with "%2B". However, Mozilla not only does not url-encode a
bogus not url-encoded plus sign in a link but also even replaces a correctly
url-encoded "%2B" with "+" in relative urls, which do not start with
"http://..". Other special characters, like space, are left url-encoded. A
url-encoded "$2B" is also preserved if the url started with "http://..". 



Reproducible: Always
Steps to Reproduce:
1. display a html page containing relative url containing "%2B":
2. e.g. on <http://k1.dyndns.org/Bilder/Artists/>
   click on the link "Valejo+Bell Sculptures" (relative url)
3. see requested url in navigation bar (bogus)
4. e.g. on <http://k1.dyndns.org/Bilder/Artists/Vallejo%2BBell%20Sculptures/>
   click on the link "Valejo+Bell Sculptures" (url starts with "http://")
5. see requested url in navigation bar (correct)

Actual Results:  
In step 2 Mozilla sends a request for a url, where the "%2B" is not left
url-encoded but even decoded to "+" instead. (my cgi script in the above example
catches this error and succeeds to deliver the referred page.)
In step 4 the "%2B" is correctly left as is.



Expected Results:  
In step 2 the "%2B" should have been left as is. 
(( Even if the url contained a plain "+", it probably should be url-encoded,
except perhaps after "?", where we can believe it might actually encode a space. )) 


To summarize: simply any character other than a-z,A-Z,0-9 and - _ . ! ~ * ' ( )
must be url-encoded! see "man url" if present.
typically not correctly url-encoded are no problem for the http server or a cgi
script, because they are preserved by the url-decoder functions, except for the
plus sign, because this is decoded to a space, thus making a difference to the
requested file path. 

there are similar bug reports which show similar problems with url-encoding the
plus sign in other places:

178149 and 233231
> if a link <a href=".:"></a> contains a plus sign "+", it must be url-encoded,

The URI RFC (RFC 2396 -- http://www.faqs.org/rfcs/rfc2396.html) says:

   Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

Note the "if the data for a URI _component_ would conflict" part.  In other
words, a '+' in the query must be escaped, but a '+' in the filepath doesn't
have to be.  In fact, the definition of characters allowed in the path is:

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

So what we're doing is in fact correct, as far as I can tell.
Assignee: general → darin
Component: Browser-General → Networking
QA Contact: general → benc
The + is no special character in any url part. For those characters it is
irrelevant if they are encoded or not. The server or any script has to deal with
that. If you want the %2B preserved you should possibly replace it with %252B.    
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.