Closed
Bug 285192
Opened 20 years ago
Closed 9 years ago
consider sending onChannelRedirect for chrome/resource channels
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Biesinger, Unassigned)
References
Details
see bug 181938 comment 18 ff. >Should we change chrome/jar channels to fire such "internal" redirects when >they open the "real" channel? This probably requires defining what exactly is a "redirect"... maybe redirect is something that changes either the URI of a channel or its instance.
Comment 1•20 years ago
|
||
Perhaps the definition should simply that any time the originalURI doesn't match the URI there should be a corresponding redirect? The problem is that this is really somehow a change of the channel API....
Comment 2•20 years ago
|
||
Let me twist this around: why *should* we do this? In theory, a chrome "redirect" is very different from a HTTP redirect: for HTTP, the new URI is used for security purposes, and displayed to the user. For chrome, the old URI is the "canonical" URI to be used for security/display, and the "new" URI is merely an implementation detail.
Comment 3•20 years ago
|
||
> for HTTP, the new URI is used for security purposes, and displayed to the user. For temporary redirects (which is what chrome is), the latter is a bug (see comments in bug 181938). Arguably, the former is also a bug. Note the INTERNAL value of the redirect flag there most carefully. Then note the code I pointed out as needing removal....
Comment 4•20 years ago
|
||
Also note the unfortunate comment at http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#6363 (in nsDocShell::OnLoadingSite).....
Updated•19 years ago
|
Assignee: darin → nobody
QA Contact: benc → networking
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•