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
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.