Closed Bug 15150 Opened 25 years ago Closed 25 years ago

URL location bar needs to be escaped before being used.

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: john, Assigned: andreas.otte)

References

(
URL
)

Details

(Whiteboard: [PDT+]) 

Using the browser on any platform, I type into the location field:

go.com.au?mozilla

and it correctly passes the query string "mozilla" to my server go.com.au,
and my server routes the user to Mozilla's home.

But if I type in

go.com.au?mozilla bug reports

it fails. The browser thinks that because there is a space character in the
location field, that each space-terminated string is an argument for
Netscape's associated search engine.

This is the wrong interpretation and the browser is actually mishandling
data. Spaces are allowed in URLs (per standard Internet RFC), being
represented in the canonical form %20 when it reaches the server. The
browser must give precedence to determining that there is a domain name. The
query symbol "?" signifies that what follows is the query string to pass to
the specified domain, not the associated search engine.

So the browser should see "go.com.au" as the domain name, "?" as a query
string following, and "mozilla bug reports" as the query string.

Mozilla is a great browser but Microsoft's Internet Explorer gets it right -
why can't Mozilla !?

Could you please correspond with me on john@go.com.au about a bug fix ? We
do not want to have to say to people that they need a Microsoft browser to
use our service. Ugh!!

Yours sincerely,
John Southgate

Go Publishing
john@go.com.au
go.com.au
Assignee: shuang → german
Re-assign it to german to look into the problem: I don't think it is a UI design
problem , though.
Severity: critical → normal
Also chage to normal severity since it is not a crashing bug.
Assignee: german → gagan
Component: UE/UI → Necko
Status: NEW → ASSIGNED
Summary: Location field misinterprets a query with spaces → URL location bar needs to be escaped before being used.
Target Milestone: M13
Ah!.... yes we do need to nsEscape::Escape the location bar before handing over
to Necko. Updated summary as well.
I played around with urlencoding and got something working locally. No need to
call for IE. This should also fix some of the other urlencoding bugs.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
This is not escaping URL's as of 2000010308. If you enter http://www.foo.com/foo
directory/, Mozilla strips off everything paste the space. While the RFC's do
not *require* a browser to escape spaces, I think Mozilla should. I cannot begin
to count how many newbies post in the Netscape support groups about how their
pages and or pictures do not load in Netscape and work in IE. These are usually
due to spaces in the URL not being escaped by Netscape and IE escaping them. The
RFC's say it is the user agent's choice so why not have Mozilla do this?
Assignee: gagan → valeski
Status: ASSIGNED → NEW
I want to give this to Jud because spaces in the location bar relate to how we
do internet keyword lookup.
*** Bug 20670 has been marked as a duplicate of this bug. ***
QA Contact: claudius → tever
I just found a problem w/ keyword processing (confusion w/ space and question
mark locations) and fixed it. This is now a URL impelementation bug (which
Andreas seems to have fixed).
*** Bug 23486 has been marked as a duplicate of this bug. ***
Assignee: valeski → andreas.otte
assigning this bug to me per Judsons request
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed by Andreas' changes that I just checked in.
Status: RESOLVED → REOPENED
reopened because of backout
Target Milestone: M13 → M14
This will not make it into M13
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
This one is fixed now.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verified:
NT 2000020708
Linux 2000020708
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.