From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m16) Gecko/20000505 BuildID: 2000050513 When using multiple browser windows, Mozilla doesn't display the correct content in some windows: it tries to load the page from the wrong site. This only seems to happen when using an HTTP proxy, not with a direct internet connection. Reproducible: Always Steps to Reproduce: 1. Load HTML pages from two different sites in two windows 2. middle-click on a link in one window to open a new window with a new page from this site 2a. if that didn't produce an error yet, repeat in the other window Actual Results: Say we have loaded http://foo.com/ and http://bar.org/ in two windows, and want to display http://foo.com/new/page.html in a third window. The location field on top displays that URL, but the actual page loaded is http: //bar.org/new/page.html, which usually gives a 404 error message.

Did anybody read this bug report from me? Should I vote for it? Did I choose the wrong component? It is still marked unconfirmed, but this bug happens to me all the time when browsing with Mozilla and makes it rather unusable for me, since I always have lots of seperate windows when browsing. I've just seen an even easier way to reproduce this bug: - Configure Mozilla to use an http proxy, as I said before, - load http://frankfurt-inline.de/ , - while the page is still loading, click on the top left link called "TNS Frankfurt" (maybe you need a not-so-fast Internet connection for this), - if you still didn't get the "forbidden" error message, click on the "back" button and try again If you need more details, please tell me.

You have the right component and the bug report seems well enough. It may be that no one who has read it has a proxy to test with.

You can set up a small local proxy quite easily with junkbuster, see http://junkbuster.com/ijb.html or http://waldherr.org/junkbuster/ for more info. As a neat side effect, you can configure it to block banner ads. :-)

NB: Junkbuster doesn't work with HTTP 1.1 (which Mozilla uses by default). st.n@gmx.net - are you using Junkbuster? Set: user_pref("network.http.proxy.keep-alive", false); in prefs.js to turn off HTTP 1.1. Gerv

Yes, I'm using Junkbuster and indeed with this user_pref workaround I don't get this bug any more. Finally Mozilla gets kind of usable - thanks! But I would still consider this bug alive, since IMHO Mozilla should be able to talk to 1.0 and 1.1 servers or proxies by default. Or is junkbuster doing anything wrong? Sorry for the delay, but I wasn't able to check this out because of other bugs/crashes in Mozilla and due to other work.

setting to NEW

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

Changing platform and OS to All/All as suggested by wdormann@crosswinds.net in a comment to bug 42131.

I've noticed new HTTP version settings in the debug prefs, so I'm changing the summary to something more appropriate IMHO.

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

future.

Could this be yet another manifestation of bug #20145? The behavior I got in recent builds (M17 nightlies) is the same as the symptoms of that bug, but the workaround listed above fixes it. Are these two bugs related?

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

This may or may not be related, but a request for htt://www.domain.com/ followed by a request for http://www.domain.com:8000/ exhibits the same behavior (namely pulling requests from the wrong server). I say this may not be related because the HTTP/1.1 keep-alive work-around does not seem to fix it.

I think the proper prefs.js option is user_pref("network.proxy.http.keep-alive", false); instead. The suggestion above doesn't work for me.

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

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

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

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

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

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

Adding mostfreq keyword.

Nominating for user release note. This is reasonably important :-) Gerv

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

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

please add mozilla0.9 keyword! it's a mostwanted so I think it should be fixed as quick as possible! is there a possibility to auto-detect the http-version of a proxy server? if not make it a pref under "proxies" to turn 1.1 off

If this isn't fixed, please make sure that "junkbuster" appears in the release notes, and not a reference like "proxy that uses HTTP/1.0." I think the average Joe wouldn't know what was being referred to unless specific products are mentioned.

I'd like to release note this but I'm not sure what it's about. Could someone summarize for me?

Summary: Mozilla needs to be configured to work properly with proxies such as Junkbuster that do not support the most recent HTTP specification. By default, Mozilla tries to use HTTP 1.1. To use with Mozilla with a proxy that only supports HTTP 1.0, edit the HTTP Version from 1.1 to 1.0 in Edit -> Preferences -> Debug -> Networking. Please edit for spelling, grammer, wording, semantics, correctness, as you see fit. I don't know if there are other specific proxies for which this is a problem. If there are they should probably be named as well.

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

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

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

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

pulling in ruslan's necko bugs ->darin

adding relnote to http://mozilla.org/releases/mozilla0.6/

http bugs to "Networking::HTTP"

Removing myself from the list of cc's.

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

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

How do I set the HTTP version to 1.0 without rebuilding to enable the debug preferences?

It is described above in the comment 2000-11-17 05:41 from Stephen Ostermiller and also in the release notes: http://www.mozilla.org/releases/mozilla0.7/#general , look for the headline "Proxies".

Ummm... Wasn't the question about builds without the debug preferences compiled? I don't know how to change the pref in such builds.

you can set the pref "network.http.version"

With recent nightly builds (e.g. 2001012904 Win32) I have to turn off "Enable Keep Alive" as well as setting the HTTP version.

Has someone filed bugs on Junkbuster and any other proxies we're seeing this on?

I sent an email to the folks at JunkBuster when this was reported. Whether or not it is a real "bug" to only support http 1.0 or not is another question.

Is there any way we can detect the proxy barfing and fall back to HTTP 1.0? Gerv

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

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

I'm having some trouble getting Mozilla to cooperate with Squid (http://www.squid-cache.org), primarily when dealing with form submission. Could Mozilla's http 1.1 use be related to this? That is, does Squid react badly when http 1.1 is used?

My recollection is that HTTP 1.0 and 1.1 should be painlessly forward and reverse compatible. If this is the case, then there is something wrong with the way we talk to Junkbuster, and possibly with the way we handle headers in our requests or responses. I'm going to put this on my list of problems to analyze, but I have a couple other projects at the top of my list of proxy issues. Does anyone want to jump start a discussion on this in the newsgroup?

Turning keep alive's off also solved it for me. I haven't had to change to HTTP 1.1 and so far it's looking good (Linux, Milestone 0.8)

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

Just came across this bug while trying to figure out why Mozilla was behaving strangely with my Proxomitron (see "http://proxomitron.cjb.net/") proxy. With Proxomitron Naoko-3, which seems to be an HTTP 1.0 proxy, I had all manner of keep-alive problems. However, setting HTTP version to 1.0 and disabling Keep-Alive in the debug preferences of Mozilla did NOT make any difference. (this is Mozilla 0.8.1 release running under WinNT 4.0). I was able to make Proxomitron work correctly by setting some rules in it to rip out all outgoing "Keep-Alive:" headers, and forcing in a "Connection: Close" header. Testing out a beta release of Proxomitron Naoko-4, which DOES support HTTP 1.1, made all my problems go away. I mention this for the edification of anyone who, like myself, comes across this bug report while having Proxomitron problems.

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

Interestingly, recent builds work with Junkbuster without having to futz with the debug settings (keepalive or http version). (e.g. 2001-0404-04 Win32)

cool! marking WORKSFORME. please reopen if you're still seeing the problem.

FYI It works for me as well, using Nightly 2001040404 on WinNT, AdSubtract Pro proxy, and browsing to http://www.pcmag.com. All Debug options are at default values.

It works for me too. But that leaves one question. What has changed that fixes this bug? Does anyone know, or are we going to leave it at this?

this is a really old bug... many things could have fixed this.

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

This is back again, I have to turn off Keep-Alive in Edit/Preferences/Debug/Networking when using Junkbuster. using 2001072303 win-32. See also bug 90673.

Yes, you will need to set the http-version to 1.0, and probably disable keep-alives as well (as mentioned in the junkbuster documentation) The patch for bug 84264 went in, and this will break junkbuster, because, in combination with the fix for bug 87047, we will now do keep-alives to http/1.1 servers without a connection header, and reuse connections to proxies to talk to multiple servers. This is valid since persistence is hop-by-hop. junkbuster keeps a connection open directly between the client and the origin server, basically tunneling the connection (which is prohibited by the specification). It does this even though it strips the connection: header (which is required by the http/1.1 standard, but junkbuster doesn't support that version of the spec). Junkbuster identifies itsself as having whatever http version the end server does (Which is prohibited by the specification), so restricting this optimisation to a particular version of http (ie > HTTP/1.0) won't help. Resolving INVALID. Also see bug 91711 and bug 90673.

That first bug should be bug 91771, sorry.

This bug should be reopened, or a new bug filed. This really doesn't have anything to do with Junkbuster, but it does have to do with proxy behavior, and the bug which seemed most appropriate for the behavior I see was marked as a dup of this one. Starting with the nightly build I downloaded Tuesday, Mozilla is now causing frequent (90+ percent of websites) proxy errors. Last night's build does the same thing. This behavior is a complete blocker for me; I had to go back to the last build I had backed up on my computer, which was 2001071704 (Windows NT), to get normal behavior. Please don't let this behavior get into 9.3!

For a long time, I had suspected something strange was going on, and apparently in some of the other junkbuster bugs, bradley has figured out that it isn't the most compliant product.

It's not only junkbuster. Here at work i'm seeing the same thing with the nightly i downloaded a few hours ago. It takes a lot of patience surfing through some sites (trying Slashdot as i type this.) I'm not sure which proxy we're using over here, and nobody will tell me either. :) I'm pretty sure it's not Junkbuster though. It's more likely some vague solution by Microsoft (i guess, because they are 'our' designated 'favorite' supplier)

We have Microsoft proxies here where I'm seeing the problem as well. And again, on my machine, I'm not using Junkbuster. But this was the bug that seemed to be the most fitting for the problem I'm seeing.

Casey: Does it work if you set the http version to 1.0? What about if you disable keep-alives (with the http version set to 1.1)? (You can do this in the debug pref panel) martijn: You can probably find out what proxy server you're using by telneting to the host and port, and doing: GET http://www.mozilla.org/ HTTP/1.0 Host: www.mozilla.org <blank line> and then looking at the Via: line in the response headers. benc: Can you point me (separately) to an in house ms proxy server? This may be a separate bug... Does this happen if you get a build from last Friday morning (Jul 20)?

If I turn keep-alive off and set http version to 1.0, the problem goes away. But what happened in the last couple of days to make this necessary? (I haven't been able to test last Friday's build as yet). Additionally, if whatever it was that changed this isn't going to be fixed, the Release Notes should detail the solution, though many users might not look at them before giving up.

Casey - we now better reuse connections to proxy servers. Can I get some packet traces of connections to the server, just so that I can see whats happening? (both from mozilla and from ie) Does it work if you leave keep-alives on, but set the http version to 1.0? (IE defaults to 1.0 for proxy servers) Can you attach packet logs with ie set to use http/1.1 to proxy servers as well?

Sorry to disappoint you, Bradley, but I don't know how to do all that packet traces stuff you spoke about. If you could give some brief directions, I'd be happy to oblige.

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

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

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

Changing summary to hopefully catch dupes, and to reflect that this bug is only about junkbuster. If people are seeing this on other proxy servers, then they need to open a new bug For details on why, see my comment of 2001-07-23 22:00. For a workarround, setting your http version to 1.0 may help (as specified in the mozilla release notes, and in the junkbuster FAQ page). Junkbuster is not http/1.1 complient (or http/1.0 compliant)

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

It seems a bit unfair, at this late date, to say this bug only applies to junkbuster, since many of the comments have dealt with proxies in general, and more importantly, because many other proxy-related bugs that said NOTHING about junkbuster have been marked duplicates of THIS bug.

Casey: every report on this page (and all the dupes) refers to junkbuster. Yours was the only exception, and I think that it may be a separate bug. We can't fix the junkbuster bug - its a bug in the software. http is forwards compatible, except when proxy server completely breaks the spec. If you're still seeing this error with MS proxy, can you file a new bug, assinged to me, and mention the exact text of the error. Do you get the same error if you change the pref in IE to use http/1.1 for proxies? You can work out when we stopped reusing proxy connections this way by looking at when the dupes stopped being reported :) (For the record, the "mozilla bypasses proxy" bugs which were marked as dupes are the same problem; junkbuster only logs the first requst made for a persistent connection, so it looked like the proxy was being bypassed)

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

Hey! I filed a bug on a Microsoft proxy a while back, and it was marked a dupe of this.This is NOT just a problem with Junkbuster.

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

Sigh. OK, I missed bug 61119 as the dupe. From the error message there, it appears that ms proxy is broken too. Looking at bugs fixed in SP1 like http://support.microsoft.com/support/kb/articles/Q239/4/95.ASP, you may end up with problems anyway. If you run into that sort of problem, then install SP1. The junkbuster problem has no client side work-arround. We cannot fix it in the browser. If the MS proxy problem stays in this bug, then it will not ever be fixed, because the junkbuster bug CANNOT be fixed on the client side. The MS-proxy one may be able to be worked arround, so I've moved that into bug 94753. If it turns out to be a proxy bug (and the advice to disable http/1.1 mentioned in the error mesage of bug 61119 certainly hints at that), then I'll dupe it against this, and change the summary.

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

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

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

Since this is so frequently encountered, how about following IE5.0 and making it the default that Mozilla does not use HTTP/1.1 (for proxies only)? This would improve the out-of-box experience for people using broken proxies, although perhaps it is better in long run to make people experience this to get the proxies fixed!

The problem is that that would disable keep-alives to proxy servers, and disable some of the cache algorithms on the cache side, which would slow things down a lot. It has been discussed that we should have a separate pref for whether proxies should be talking 1.1, but I still think that 1.1 should be the default. Since this only affects Junkbuster (and one other server called "CookieCop Plus", originally published by PCMag). I'd prefer not to do this. Junkbuster doesn't add any header linss, so we can't detect that we're using a broken proxy and disable keepalives that way. If someone wants to come up wioth a patch for junkbuster to not blindly forward the http version, that would be great. I may do so at some point, if I find time.

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

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

i agree with bbaetz. http/1.1 persistent connections were designed with proxy servers in mind, and to disable http/1.1 by default just for compatibility with a broken proxy seems like it wouldn't do anything to help the situation. it's a noble goal, trying to build a browser that is compatible with everything out there, but at the cost of improving the performance of the internet, i think we really must maintain http/1.1 as our default http version.

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

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

Clearing target milestone to avoid confusion in the most frequent bug list.

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

A simple solution that would placate both sides of this issue would be to extend the image blocking capability in Mozilla to block URL regexps. This would subsume the need for people to use a broken proxy server (junkbuster). The current image blocking is indeed a nifty feature (I started using Mozilla as my primary browser when this feature was added), but it being so limited to having to manually deny each ad site (ad1.annoy-me.com, ad2.annoy-me.com, ad nauseum) as well as not being able to block simple sub-site hierarchies (www.good-but-ad-supported-site.com/banner-ads/*) necessitates that many are required to retain the junkbuster proxy. The URL regexp matching code in junkbuster is quite small and could easily be added...

mozilla.org@kswanson.com: see bug 91783 for that.

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

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

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

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

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

For those of you who still use JunkBuster, and would rather you don't have to F around with the clients in order for them to behave, the following parameter in the JunkBuster config works for me: # add an "X-Forwarded-For:" specification to each request header # add-forwarded-header I'm not sure exactly WHY it works, but it appears to. Hopefully this will help other people with the same problem.

That does nothing. It only adds the "X-Forwarded-for:" header to the GET request. Because HTTP 1.1 still doesn't work, you still get the bad behaviour. Try it. Set your HTTP ver to 1.1 in debug->networking.

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

add-forwarded-header didn't seem to work for me either ....

Yes, I was full of **** there. It seemed to work, apparently because the cache was skewing my results. However, in addition to just setting HTTP/1.1, you can also turn off "Enable Keep-alive". This is confirmed to work. It's the keep-alive that confuses junkbuster.

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

there is a newer version of junkbuster available at: http://sourceforge.net/projects/ijbswa/ which MAY resolve some of the issues described

From their project plan: Next Release 3.4 ================ -http/1.1,persistent connections, H I don't think http 1.1 support is implemented yet.

We don't want 1.1 support, just HTTP/1.0 support. I'll check cvs, and file a bug with them if its not fixed.

I contribute to the project at http://sourceforge.net/projects/ijbswa/ Yes, it does support the HTTP/1.1 protocol. As has been indicated, persistent connection is planned for a later date. Our proxy properly accommodates the persistence issues as per the rfc's, so there is no need to downgrade a browser back to the 1.0 protocol. Hopefuly it can handle any valid construct you can throw at it. I and others on the project are fully aware of this bug caused by the old Junkbusters 2.0 version. We understand exactly what it is and we have captured detailed logs of it. This is Not an issue in our product. Our project is entering a Beta period where we will shake out various issues before rolling out the next major version. You are all welcome to get our latest versions for whatever platforms and give it a workout. We would welcome any bug reports, feature requests, etc. Ours is also a completely open-source project. We have many additional features and enhancements that are beyond the scope of the old Junkbusters 2.0 product. Anyone accustomed to that should be quite pleased with what we have to offer, not the least of which is full compatibility with Mozilla. We are not the original developers of the Junkbusters proxy and we are not affiliated with Junkbusters.Com. As our project continues to evolve we may no longer be able to claim to be a "Junkbusters" proxy, though the ancestry is still obvious today.

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

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

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

relnoteRTM -> relnote added "proxy" to subject for searchability

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

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

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

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

My, bug (111652) has been marked a duplicate. Also, I see *this* bug is marked as RESOLVED. However, I am NOT using the 'JunkBuster' proxy server. (I am using 'Sambar Server' (Sambar.com) for a proxy) REGARDLESS of what proxy software I'm using, this bug manifests in Mozilla and NOT in NS4x or IE. In the court of public opnion, if other browsers DO work correctly and Mozilla does not, marking this resolved is analogous to 'guilty-no-contest' -the average user doesn't care about underlying protocols, they measure status-queo betw other browsers and this one -behaving in an expected fasion -and will ONLY blame this browser -and continue to send in 'duplicate' bug reports. Very respectfully, ken

This bug *is* invalid. Junkbuster is broken when using HTTP/1.1. It breaks the HTTP/1.0 RFC by forwarding the entire status line from the origin server to the client. This breaks the fundamental part of the forward compatability rules, since the client cannot know what it is - see other discussion in this bug for the problems it causes. Since junkbuster doesn't identify itsself, there is no way that we can automatically detect this. ns4 only uses http/1.0, and IE disables HTTP/1.1 for proxies - (there have been unconfirmed reports that some of MS's proxy servers have the same problem) You can disable HTTP/1.1 by following the instructions in thies bug, and then it will work. This will, of course, decrease the performance of the browser, which is why we don't default to HTTP/1.0. If you're not using junkbuster, your proxy server probably has a similar problem. I see you're reopened it - someone will look into it, then.

I just wanted to apologize for my last comment very possibly sounding too critical, but I really love this effort and want to see it succeed. I cant emphasize enough that its the average user we are dealing with -who will blame this behavior on the *one* piece of software where they see it manifest. There is also a *haunting* security implication anytime *any* data is GET/POSTed to the wrong host. Would defaulting to http/1.0 proxies be prudent here (if we cant test the proxy's http version)? Thank You for the synopsis response by the way.

Currently the pref for the proxy version and the server version is the same. Darin has a bug somewhere to separate those, but I can't find it ATM. Maybe the default for that should be 1.0. the problem is that a lot of the perf improvments for 1.1 are aimed at proxies. Maybe we could just have a separate pref, disabled by default, to reuse the same proxy connection to different hosts. I have the feeling that that woudl just make the problem more subtle, since thats not the only difference between 1.0 and 1.1 The security issue is the proxy's fault - we tell it what host to send data to, and it ignores us, whilst claiming that it follows the http/1.1 spec.

I'd just like to point out that the current development version of junkbuster, http://ijbswa.sourceforge.net/ , has HTTP/1.1 support and shouldn't suffer from these problems. Unfortunately it's still in alpha, but it could be worth pointing out to junkbuster + mozilla users.

Might I suggest that Mozilla resolve its proxy issues the way that Opera does. Most people using Opera through proxies might be surprised to find out that it really is a HTTP/1.1 browser. When a proxy is configured, Opera sends a "OPTIONS * HTTP/1.1" request to that proxy as the first communication with it. This is done once and only once in the browser session just before the first "real" request to the proxy. Below is a snapshot of those request headers using the old 5.11 version: OPTIONS * HTTP/1.1 User-Agent: Opera/5.11 (Windows 98; U) [en] Host: 172.20.1.115:8000 Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */* Accept-Language: en Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Connection: Keep-Alive Note that the Host: header targets the proxy itself as configured to Opera. If the proxy responds with anything other than "HTTP/1.1 200 OK" then Opera will communicate using HTTP/1.0 with the proxy for the rest of the session. If the proxy responds with "HTTP/1.0" or if it responds with other than 200 then it's treated as a HTTP/1.0 proxy. On the other hand, if the proxy responds properly to the OPTIONS request then all future communication with it will use the HTTP/1.1 protocol and features, including connection persistence, TE: headers, etc. I haven't been able to find any documentation about this on Opera's or any other site, though it surely must be out there someplace. It seems to be a reasonable solution since it places the burden of protocol determination on the proxy and gives it a chance to indicate whether it can handle the HTTP/1.1 protocol. Many proxies can not, and this provides quick and easy detection of them. The method works without end-user involvement or special configuration options. Unfortunately, I can't tell how many "capable" proxies this falsely identifies as being the old HTTP/1.0 generation (anybody know somebody at Opera?). I doubt that any of the old "incapable" proxies would be falsely identified.

very interesting suggestion. i just tried it with a proxy server that i know supports HTTP/1.1 and i unfortunately got a 500 response. so, i'm not sure how realistic this approach would be. IMO at the bare minimum, it would be good to provide checkboxes in the proxy server configuration preferences panel to downgrade to HTTP/1.0 and/or downgrade to not using persistent connections to help with bad/broken/old proxy servers.

Opera released their new version 6.0 today and that version no longer issues the proxy's OPTIONS request. Perhaps they had good reason to stop doing it. Opera 6 now seems to be using the response from the first real (GET) request to determine what protocol to use through the proxy. The first GET uses HTTP/1.0, and if that request's response comes back as HTTP/1.0, then that's what it always uses for the session. If the response contains HTTP/1.1 then it always uses that instead. I don't like this approach since the HTTP response may depend upon the particular target site as well as the proxy(s). Performance and features could be radically affected by an individual's choice for the first request (often the home page). I really wanted to see the OPTIONS method succeed because that would have given the proxy's an opportunity (or really a responsibility) to be involved in the protocol level determination. While I agree completely that a user should be able to specify a setting, most users will not have a clue what to select. There should be some way for proxies and browsers to work together to determine a best-guess protocol level based on the technical environment at hand.

> I don't like this approach since the HTTP response may depend upon the > particular target site as well as the proxy(s). This is incorrect. It _should_ only depend on the proxy - thats the bug here. Checking the first site won't help - you'll still have the same problem

bbaetz: exactly! the thing about the extra preferences in the proxy panel is that users could then try those if the browser has problems. we could make the text for those preferences very user friendly... "try this if you have problems accessing the internet through the proxy server" etc...

darin: You own the bug on a spearate pref for proxies, IIRC...

right, and one day i plan to fix that along with the preferences panel for proxies.

>> I don't like this approach since the HTTP response may depend upon the >> particular target site as well as the proxy(s). > This is incorrect. It _should_ only depend on the proxy - thats the bug here. > Checking the first site won't help - you'll still have the same problem No, I believe my original statements are correct. Perhaps that is the crux of these proxy issues. I've gone back to the RFC's and I very much disagree with your position. Various quotations below are from RFC 2616. Your statements presume that any proxy must alter the protocol level of origin servers into one, either all HTTP/1.0 or HTTP/1.1. That presumption is not a requirement of the protocols. If you mandate or assume that for all proxies then your product will never operate properly with proxies that function as Transparent Proxies, Gateways, or Tunnels (as they are defined by RFC 2616). By definition of what it is, a Transparent Proxy will not alter a HTTP/1.0 server's response into HTTP/1.1 (or visa-versa) before sending that response back towards the application. The version of a response depends upon the upline server(s) and not just the immediate proxy. I can not understand how a Transparent Proxy can coexist with your presumption of a single protocol version for all responses. If you will not support even transparent proxying then forget about all of the non-transparent variants. ----- (Section 1.3 in the definition of "server") "Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request." Your product should be able to accommodate responses from a "server" which responds differently based on the nature of each request. As virtual sites and sub-domains proliferate, even some servers that aren't proxies can and do respond to different kinds of requests using different protocol versions. This is often the case where the "server" is a front-end to multiple "origin servers" as defined by the RFC. It seems you can not require a specific protocol response version from a server, even when a proxy is not involved in the stream. Would it break your application if Yahoo served back GIF images using HTTP/1.0 and HTML content using HTTP/1.1? ----- (in Section 1.4) "In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with or deployed across the World Wide Web. {..snip..} The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while introducing protocol constructs that meet the needs of those who build web applications that require high reliability and, failing that, at least reliable indications of failure." As RFC 2616 is over 2 years old, the complexities have continued to grow. Often a proxy/gateway is only one in a series or network, with various requests being channeled through different paths depending on each request's particular attributes. The assumption of one-on-one clear conversations between a client and the world of servers was invalidated even before HTTP/1.1 was proposed. ----- (Section 3.1) "Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST NOT send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway MUST either downgrade the request version, or respond with an error, or switch to tunnel behavior." These statements do NOT require that a proxy compliant with the HTTP/1.1 protocol to upgrade /1.0 Responses to the /1.1 protocol. It actually seems to caution against the effects of protocol re-versioning. It does pose restrictions on what a proxy should do with something like a HTTP/3.9 request, but note also that it could just pass that unknown version on using tunnel behavior without being non-compliant. ----- (also in Section 3.1) "Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MUST be in the same major version as the request." If a proxy is acting as a tunnel for a particular request, then it must follow the Transparent Proxy rules and leave the protocol version untouched. Only a caching proxy "MUST" upgrade a protocol version. Is this the source of your presumption? There exists at least as many non-caching proxies as those that do. Note that it is only the "major" version that must be the same as the request. HTTP/1.0 and /1.1, (and later /1.2 etc.) are acceptable to use as response to any HTTP/1.* request. Will your application break the first time it encounters a HTTP/1.2 server response? ----- (Section 9.2 OPTIONS) "If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof)." It still seems like a good idea and much better than anything else I've heard. At least it gives a proxy the chance to indicate its own preference. ----- The title of this bug is "Proxy:junkbuster is broken - use http/1.0 to get arround this". I further qualify that it is the old Junkbuster 2.0.x version that is broken. That version breaks browsers with a mis-assumption of persistent connections, as triggered by configuration of HTTP/1.1 to the proxy. A broad solution would be to restrict the assumption of proxy utilization to the HTTP/1.0 protocol level and let the users decide whether to try the newer protocol. I was suggesting the OPTIONS method, but I wish I knew why Opera may have stopped using it. Presuming or requiring a homogenous protocol response level from any proxy or any other kind of server will introduce new problems for you with a multitude of other proxies, gateways, etc.

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

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

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

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

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

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

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

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

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

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

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

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

Mass removing self from CC list.

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

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

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

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

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

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

Verified invalid.

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

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

i've run into this one from time to time _without_ using a proxy. it's possible that my dialup isp is using a transparent proxy that exhibits the same bug, but i don't know if that's the case or not.

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

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

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

as the HTTP Options dialog will go away with Mozilla Firebird as default browser, shouldn't the default setting for proxys changed to HTTP 1.0? This has collected 71 dups (place 4 in the stats), I think that's enough to change the default!

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

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

hhhhhhhhhh