Need to pass transport layer messages up the stack so that they can finally be displayed on status bar.

They'll probably need to get marshaled just like stream listener messages. We should use the proxy event stuff for this (and redo the stream listener stuff to use it too eventually).

*** Bug 10333 has been marked as a duplicate of this bug. ***

Marking as blocker...need fix for QA automation ASAP please.

Bill sez the XPApps team needs this for better status/progress.

Not a blocker to QA automation. Taking off 11349 depends list.

this sounds like a protcol specific thingy that will take effort during m11. moving off the m10 list

mscott maybe has relevant mailnews techniques. /be

Is this why apprunner says `transferring data from {proxy hostname}', when it should be saying `transferring data from {Web server hostname}'?

Gagan, didn't you fix this?

Changing Summary field from: Transport layer messages (for status/progress)

->m12

I already fixed this but need a review and will check it in tonite (back to m11)

This is verified using proxies on an 11/18 build. In 4.x, we briefly display the proxy host, wonder if we should do it in 5.0...

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

Since we have added support for more robust network connection proxying, I think we need to change the status messages so they behave more like they did before, where you could see what proxy was being contacted. Right now, it says "resolving host <URL.fqdn>." While doing DNS resolution to the proxy server, it should say: "Resolving proxy <proxy.fqdn>". Then, it should say: "connecting to host <URL.fqdn> via proxy <proxy.fqdn>. This would be ideal, because it is very accurate without being needlessly technical. For users of PAC files or SOCKS+application proxies or failover, this display would be very informative. This also helps because http proxy errors are returned as HTTP status 4xx and 5xx w/ HTML. Correct status bar text would compliment those situations.

> "connecting to host <URL.fqdn> via proxy <proxy.fqdn>. Ewwww. I'd rather not get told which proxy I'm using for every dang page I load, thanks. Providing informative wrappers for HTML errors is part of bug 28586.

Adding a pref for that might be a good idea, but we need this feature. console logging was removed (bug 85290), the lack of a display for which proxy is used for a URL is going to make PAC debugging and support a difficult problem.

> console logging was removed You can still enable much logging via environment vars. See PR_LOG. The current messages, "Resolving host www.mozilla.org", are plain wrong (I think).

Oh, my comment does not apply to the bug you cited, sorry.

I doubt this is a blocker any more, and m11 is long gone. Also see bug 94038.

->darin

we currently display the real hostname. that said, i agree w/ mpt's comment #16 and ben's comment #18. what we probably need to do is display the proxy servers address in the "Resolving" messages, and the real host in the other messages. and of course, DNS errors need to report the proxy server name, not the real host name, and should probably also include the word "proxy server" so users will have some better context. at any rate, i think we can live w/ the current behavior for mozilla 1.0 -> future

Didn't 4.x do the right thing here? My testing with proxy.meer.net:8080 shows that it does. That raises the priority of this bug in my book, if not in darin's :-). /be

I can dream, can't I? /be

I changed this a while back so that you can call GetHost and GetPort on the socket transport. That was done to support cocks proxying which the channel doesn't know about, and it should probably be exposed a bit higher up (nsIChannel, maybe, before thats frozen?) IE is this fixed for socks proxies? The "can't contact host" errors shoudl be fixed too - that causes confusion when you have proxies set up incorrectly. Who puts those up? docshell? uriloader? Technically, "transmitting data from <realhost>" could be wrong, not only because of caching, but proxy error messages. Thats an edge case though, and I wouldn't worry about it, especially since we have no way of distinguishing those cases.

bbaetz: nsWebShell::EndPageLoad is currently responsible for putting up the DNS error dialog. it would need to get at the nsIProxyInfo for the channel, which might indeed mean changing nsIChannel (if we want it to be something generic) or adding a nsIProxiedChannel (yuck). ok, so making this depend on bug 128508, which pushing this bug back on the radar for mozilla 1.0.

But you can get it off the nsITransport now, via nsITransportRequest, can't you? Is that freezing for 1.0?

that doesn't buy us anything... nsWebShell doesn't see transport requests... it sees channels.

But the channel could implement nsITransportRequest. That probably won't work for http, though. Can we just add a GetFirstHopHost/port to nsIChannel? Then the channel could take care of asking the transport. You'd also have to differentiate between connection errors with the proxy, and those with the host, which may be a problem for socks - I'm not sure if the transport code would have to be modified for that.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

oops.. did i forget to add topembed to this ;-)

bbaetz: i really don't like the idea of using nsITransportRequest for this. it wouldn't even be a direct path to the proxy info. it seems to me that we should provide a direct method to get to proxy information. as far as distinguishing host DNS failure to proxy-host DNS failure, we could achieve that w/ a different nsresult... maybe.

*** Bug 130300 has been marked as a duplicate of this bug. ***

EDT topembed- not critical for embeddors. If you're aware that this is a problem for embeddors, please let us know. Thanks!

this bug doesn't require changes to nsIChannel or any of the other soon-to-be-frozen necko interfaces, and seeing as time is running thin... i think i'm going to have to defer this bug until post 1.0 :(

*** Bug 56629 has been marked as a duplicate of this bug. ***

Copying deps from the dup bug 56629

mass futuring of untargeted bugs

*** Bug 155284 has been marked as a duplicate of this bug. ***

+nsbeta1 - this used to work, and it would make dealing with proxies much easier.

benc: there is the matter of overly complicating the status messages. people ultimately only care about the proxy server if it isn't working, and when it is working they only care about knowing what origin server they're hitting. so, i'm not convinced this bug should be fixed. that said, i am totally in favor of adding more feedback when there are problems related to the proxy configuration.

right. and lets not change the summary-- which changes the meaning of the original bug. pls. revert it back. thx.

I'm just trying to make the meaning clear. If I got it wrong, please change it to what you like. The original was "Transport layer messages", but I don't think that was meaningful to most contributors. If what I'm thinking of is significantly different, I'll create a new bug.

there. now don't touch it ;-)

WORKSFORME linux 2002090312 trunk :)

VERIFIED: Netscape 7.0, allplats I think the format I suggested isn't too complicated, and it would easily tell a user what is going on. If people only used manual configs, I would agree w/ Darin, but when you use complicated PAC files, this would be really nice. That being said, I'm not going to file a new bug, if someone decides they want this and it's meant to be, I'm sure someone else will file.

benc: good point about PAC, but on the flip side of the coin, PAC is probably used a lot by folks who have absolutely no idea what a proxy server is. i'm more interested in the bug about "host not found" or "connection refused" specifying the origin server when in fact it should be specifying the proxy server (and i think that bug is filed elsewhere).

filed bug 167028 about adding a status message for connecting to the proxy (i.e. part of benc's suggestion).

PAC files are indeed used by people who have no idea what a proxy is, in which case the PAC file is provided by a corporate or ISP administrator (or put-upon housemate, I suppose). In that case, being able to ask the user "what does it say in the status bar when it's just sitting there?" would be a minor miracle, and would contribute materially to the quality of both the user's and the administrator's lives. (In a former life, I spent literally days debugging dynamically generated 4.x PAC files at a VAR installation, with a combination of crappy tools like tcpdump and netcat. I'm generally a bit fan of writing for "diagnosability" -- no silent failures, etc. -- but this case is especially close to my heart.)

we're drifting, I've moved the last set of comments to the new bug...