Closed Bug 285192 Opened 20 years ago Closed 9 years ago

consider sending onChannelRedirect for chrome/resource channels

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
normal

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.
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....
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.
> 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....
Also note the unfortunate comment at
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#6363 (in
nsDocShell::OnLoadingSite).....
Assignee: darin → nobody
QA Contact: benc → networking
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.