Closed Bug 61167 Opened 24 years ago Closed 24 years ago

nsHTTPChannel::GetURI returns wrong result when proxying

Categories

(Core :: Networking: HTTP, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED INVALID
mozilla0.9

People

(Reporter: bbaetz, Assigned: darin.moz)

References

Details

Attachments

(1 file)

nsHTTPChannel::GetURI always returns the uri passed in. For ftp proxying (and
gopher), this uri is a garbage (but syntactically valid) uri (http://test.com
for ftp).

If you then get an html page with isindex (like a gopher query page as
constructed by squid), layout ends up calling channel->GetURI, and then tries to
send the query request to the dummy uri (when using a proxy). The attached patch
fixes this.

I doubt it can cause a problem - if somewhere was getting "http://test.com" back
as the uri and trying to do something with it then it was broken anyway

As well, the status bar text is incorrect ("Connecting to test.com") The
attached patch doesnt't fix that - I can't find out where that is being set, but
it probably needs to be changed.

Note that you won't see this problem with ftp, because ftp wraps the proxying
channel within nsFTPConnectionThread.cpp, and it also does its own status
messages. HTTP/HTTPS does it as special cases as well (beacuse of the different
headers), so you won't see the problem with that, and no other protocol in
mozilla supports proxies.

Gopher is a simpler protocol, and I have NewChannel just returning the proxy
channel directly, which is simpler, and seems to match the comments in
nsIProxy.idl. Patches to support gopher are attached to bug 49334. To duplicate,
apply those patches, set up a gopher proxy, then go to:

gopher://gopher.ptloma.edu/7/v2/vs

and try a search. You'll end up at http://example.com/?search-term instead of
getting the results as expected (non proxied gopher queries don't work, so you
can't verify it with that - apply the attached patch to see the difference in
the result)
Depends on: 58872
No longer depends on: 58872
ops, accidently removed the dependency.

Bug 58872 seems to be the culprit here. Code is mentioned.
Depends on: 58872
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Target Milestone: --- → M19
http bugs to "Networking::HTTP"
nominating for moz 0.9
Target Milestone: --- → mozilla0.9
After some comments from darin on IRC, I looked into this a bit more. When
proxying, nsGopherHandler::NewChannel just returns the proxy channel, rather
than doing what the ftp channel does (ie I should return the gopher channel, and
begin most calls to the channel with:

    if (mProxyChannel)
        return mProxyChannel->Foo(blah);

)
I could do this, and I suppose it would work, but I don't think it should be
needed.
bbaetz: gopher should not expose the http channel to its clients.  it must fully
encapsulate the http channel.  it is wrong to hand out an http channel to clients
of gopher.
OK, I'll change gopher then. I don't know if this is a bug then or not.

Why does it have to be fully encapsulated? I'm offering a channel that, when
read from, gives the gopher stream requested. If theres no reason, I may just
make the test.com uri the real one, and then everything should work.
It needs to be encapsulated because people will query information off of the
channel that you hand back.  They may very well query more than just the URI.
Consider for example code that QI's for a nsIHTTPChannel.  That code might
do something completely different if it gets a HTTP channel as opposed to
some other channel.  You don't know and can't predict what people will do.
It is just far safer to encapsulate Gopher so that clients never see the
underlying HTTP channel.  Abusing necko in this way has resulted in many
subtle difficult to track down bugs.  Just don't go there ;-)
marking INVALID
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
verified INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: