Closed Bug 38488 Opened 24 years ago Closed 23 years ago

Proxy:junkbuster is broken - use http/1.0 to get arround this

Categories

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

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: st.n, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: relnote) 

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.
Summary: can't have multiple windows when using an HTTP proxy → can't have multiple windows when using an HTTP proxy
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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.
OS: Linux → All
Hardware: PC → All
    I've noticed new HTTP version settings in the debug prefs, so I'm
changing the summary to something more appropriate IMHO.
URL: http://junkbuster.com/
Summary: can't have multiple windows when using an HTTP proxy → can't use an HTTP/1.0 proxy like Junkbuster without changing debug prefs
*** Bug 40849 has been marked as a duplicate of this bug. ***
future.
Assignee: gagan → ruslan
Target Milestone: --- → 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. ***
Status: NEW → ASSIGNED
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.
Keywords: mostfreq
Nominating for user release note. This is reasonably important :-)

Gerv
Keywords: relnoteRTM
Whiteboard: relnote-user
*** 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. ***
Assignee: ruslan → gagan
Status: ASSIGNED → NEW
Target Milestone: Future → M19
pulling in ruslan's necko bugs ->darin

http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Blocks: 61691
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
Target Milestone: --- → Future
Keywords: mozilla1.0
*** 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. ***
Keywords: nsCatFood
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.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: Future → mozilla0.9.1
*** 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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
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)
Summary: can't use an HTTP/1.0 proxy like Junkbuster without changing debug prefs → junkbuster is broken - use http/1.0 to get arround this
*** 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.
Target Milestone: mozilla0.9.1 → ---
*** 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...
*** 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
Keywords: relnoteRTM → relnote
Summary: junkbuster is broken - use http/1.0 to get arround this → Proxy:junkbuster is broken - use http/1.0 to get arround this
Whiteboard: relnote-user
*** 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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
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. ***
Blocks: majorbugs
*** 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.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
*** 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. ***
No longer blocks: majorbugs
hhhhhhhhhh
You need to log in before you can comment on or make changes to this bug.