Closed Bug 10647 Opened 25 years ago Closed 24 years ago

NS_NewURL constructs incorrect URL (Redirects related!)

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rods, Assigned: rpotts)

References

(
URL
)

Details

I am not sure if this is a bug in Necko or not, but it is a problem in the
current build.

When you select an item in the combo box, JS script assigns a newly constructed
url. For example:
var d = "encyclopedia/" + (s.options[s.selectedIndex].value) + ".html";
window.top.location.href = d;

Which then ends up in nsLocation.cpp that construct a new URL using NS_NewURL

It is suppose to take the current location:
www.pokemon.com/pokedex
and append:
encyclopedia/cloyster.html
to form:
www.pokemon.com/pokedex/encyclopedia/cloyster.html

But for some reason the pokedex part gets truncated off and it constructs:
www.pokemon.com/encyclopedia/cloyster.html
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Works fine with Necko.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There seems to be a problem with the trailing slash. If you put in
http://www.pokemon.com/pokedex/ it works ok, if you put in
http://www.pokemon.com/pokedex it does not.

Gagan, to reproduce with 7/31, go to http://www.pokemon.com/pokedex then select
the drop-down menu and something like 'Bellsprout'. Then, there is some combobox
bug that you have to click once more on the combo box. The 'pokedex' part of the
URL gets thrown out.
Target Milestone: M9
This is also redirects related.
Assignee: gagan → rpotts
Status: REOPENED → NEW
Summary: NS_NewURL constructs incorrect URL → NS_NewURL constructs incorrect URL (Redirects related!)
Updated summary/assigned to.
Assignee: rpotts → gagan
Gagan, can you look at this?
I already did once and explained that its redirect related. The redirected URL
does not get reflected in the base URL for subsequent requests. And hence the
malformed URL that follows. We need to hunt down whoever is responsible on the
other end of OnRedirect (or OnStopRequest) who would look at the modified URL
and update the location bar correctly. To summarize- any URL of type-
http://www.foo.com/bar where bar is a directory MUST be updated on the URL
location bar as http://www.foo.com/bar/ for subsequent requests to work
correctly.
Target Milestone: M9 → M10
This is definitly not an URL-parsing problem. As I see it, the problem is, that
when a redirect happens there is made a new channel which replaces the old one.
The URL of this new channel has the missing /, all is fine, but whoever is
making the request is not informed of this change. So OnEndDocumentLoad is
called with the old channel and the URL of that Channel is still the
unredirected and that url is displayed in the urlbar. I think there are at least
two options:

1. Update the old channels URL ... don't like it
2. Implement the nsIHttpEventSink interface for the caller (if possible) and
change the current channel with OnRedirect
Also the URI/URL of the webshell has to be changed in case of an redirection
since this one is used in nsHTMLContentSink.cpp to build the new URL for the
REFRESH-meta-tag.
Status: NEW → ASSIGNED
Yes this is definitely the case, Andreas. Although #2 is the correct way to go.
I just have to hunt down who's responsible for making that change.
*** Bug 12912 has been marked as a duplicate of this bug. ***
QA Contact: paulmac → tever
Assignee: gagan → don
Status: ASSIGNED → NEW
don: who's responsible for updating the location bar? thx.
Assignee: don → radha
Priority: P3 → P1
Target Milestone: M10 → M11
Radha ...
Status: NEW → ASSIGNED
The urlbar is now updated in OnStartDocumentLoad() instead of
OnendDocumentLoad(). Is it not possible to send in the new channel with the
redirected url to OnStartDocumentLoad().
What about implementing the nsIEventSink interface (OnRedirect...) and let it
change the urlbar too?
Target Milestone: M11 → M12
*** Bug 10926 has been marked as a duplicate of this bug. ***
Summary: NS_NewURL constructs incorrect URL (Redirects related!) → [DOGFOOD] NS_NewURL constructs incorrect URL (Redirects related!)
Related to uri loader or nsIEventSinkGetter (what ever it is called right now)
Whiteboard: [PDT+]
Putting on PDT radar
Whiteboard: [PDT+] → [PDT+] 11/26 completion
Is it not enough if I update the urlbar in OnEndDocumentLoad() so that the
redirected url will be displayed in it?
The problem here is that there is a new channel created during redirection, but
that new channel (with the new URI) is not propagated to whoever is making the
request. As a result the channel used on the webshell (or whoever is calling)
does not contain the right url and other functions that use it fail afterwards.
This is not only an issue about updating the urlbar or not.
I still think the only option is to implement EventSink or uriLoader or whatever
for nsWebShell and let the channel (and the URI of the Webshell itself) be
updated by OnRedirect.
Target Milestone: M12 → M13
Since this depends on the new uri loader and the new webshell, moving to M13. I
won't be here next week to finish it for M12 time frame.
Summary: [DOGFOOD] NS_NewURL constructs incorrect URL (Redirects related!) → NS_NewURL constructs incorrect URL (Redirects related!)
Whiteboard: [PDT+] 11/26 completion
With jevering's permission ... I removed the PDT+ status of this bug since it's
now targeted for M13.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Assignee: radha → warren
Status: ASSIGNED → NEW
This seems more like things to be done in necko rather than a simple urlbar
update in browser code.
*** Bug 16156 has been marked as a duplicate of this bug. ***
*** Bug 15863 has been marked as a duplicate of this bug. ***
*** Bug 23286 has been marked as a duplicate of this bug. ***
Assignee: warren → rpotts
Rick, is this related to the changes you made tonight to add the
LOAD_DOCUMENT_URI flag?
Target Milestone: M13 → M15
The changes I made for bug #23055 should make this easier...  I'm not sure if
the load attributes are being propagated correctly for redirects...

I'll look at it when I get back...
I'm currently working on app (going to use Mozilla as a principal browser) that
relies heavily on redirects so this bug is a big showstopper for me. I've been
waiting two weeks hoping in M13 it would be fixed but it was just retargeted for
M15 and I cannot wait this long. I've spent weeks convincing my clients Mozilla
is the way to go and today we're going to switch to Explorer (four letter word
of your choice here). I still don't understand how bug of this importance is not
dogfood - without redirects one cannot do any sophisticated web app (no sessions
etc). Please reconsider M15 target if at all possible.
*** Bug 13143 has been marked as a duplicate of this bug. ***
*** Bug 26204 has been marked as a duplicate of this bug. ***
here's the test case
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2620

Browse to a file and hit submit.
*** Bug 27381 has been marked as a duplicate of this bug. ***
*** Bug 27035 has been marked as a duplicate of this bug. ***
*** Bug 27972 has been marked as a duplicate of this bug. ***
*** Bug 28748 has been marked as a duplicate of this bug. ***
I think the word REFRESH should be in the summary for this bug.  Maybe that 
will make it easier to find the bug in searches and lower the number of 
duplicates.
*** Bug 29191 has been marked as a duplicate of this bug. ***
*** Bug 28714 has been marked as a duplicate of this bug. ***
I can see onRedirect method on nsIHTTPEventSink. Is it still a bug?
The test URL does no longer work.
Moving what's not done for M15 to M16.
Target Milestone: M15 → M16
*** Bug 35275 has been marked as a duplicate of this bug. ***
Since the example url of the last dupe of this bug ( bug 35275 ) is working now
and the example URL of this bug can no longer be found, I think it's save to
assume that this bug is indead fixed.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Bug 27972 which is dup of this one is still not fixed
Try URL of bug 27972

verif.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.