User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.2b) Gecko/20021018 I was reading some news at www.wp.pl (a Polish portal) when I saw that some advertisements were replaced with "Bad request. Your browser sent a query this server could not understand." message (they were all in iframes). At first I didn't care about that, I just thought it's a problem with the Flash plugin or the ad-server. But today I wanted to see Sun Microsystem's website in Polish (http://pl.sun.com) and this message has been shown. Then I've loaded pl.sun.com into Netscape 7 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0) and it was displayed properly. This also applies to www.sun.com, www.sun.com.pl. I doubt if it is a server misconfiguration, because these are Sun Microsystems' servers, not some "I'm Billy and that's my homepage"-like ones... I don't know if this bug is reproducible in the original Mozilla 1.2b, I'm using Mozilla 1.2beta with text antialiasing compiled in. It comes from the package "mozilla-dropline-1.1.90-i386-1.tgz" from the Dropline GNOME suite for Slackware Linux. (http://www.dropline.net/gnome) Reproducible: Always Steps to Reproduce: 1.Start Mozilla 1.2b 2.Enter www.sun.com, www.sun.com.pl or pl.sun.com to Location bar and press Enter. Actual Results: A "Bad request. Your browser sent a query this server could not understand." message is shown. Expected Results: Display the page as Netscape 7.0 or Mozilla 1.0.x does.
marek: would be great if you could capture a mozilla log for us. just enable the following environment variables before running mozilla: export NSPR_LOG_MODULES=nsHttp:5 export NSPR_LOG_FILE=/tmp/http.log then start mozilla, repro the problem, exit mozilla, and then attach /tmp/http.log to this bug report. this log file might help pin-point the source of the problem. thx!!
I've done some additional tests - I thought that it may be problem with pipelining or HTTP version, but turning pipelining off or on doesn't change the situation, neither "Use HTTP 1.0" does.
The same problem ofccurs with the Wile Interscience website: Steps to reproduce it there: 1. Start Mozilla 2. Go to http://www.interscience.wiley.com/ Result: The page loades, but without any images Expected: page with images 3. Click on link "Journal finder" Result: Error message: Bad request Your browser sent a query this server could not understand. I am using the Windows version on Win NT 4.0 This already happend in 1.0.1, and is still present in 1.2.1
Rudolf: the page you mentioned works for me in today's nightly build (1.3a) and Netscape 7.0 (==Mozilla 1.0.x).
WORKSFORME linux 2002113005 trunk
The page I indicated in my last mail also works in Netscape 7.0.1, but not Mozilla 1.2.1, both under Windows
i'm still unable to reproduce this. linux trunk 2002120908. can you try mozilla 1.3 alpha and see if you can still repro the problem with that? thx!
Works for me, using linux nightly 2003010404. I also telnetted to pl.sun.com and repeated the query from the attached logfile; the server sent responded with an html page. Marek, can you reproduce this with a current version of mozilla?
The problem appeared only in (X11; U; Linux i686; pl-PL; rv:1.2b) Gecko/20021018 mentioned above. It hasn't been reproducible in any later Linux build. So maybe it was something wrong with that specific build, which probably was not an official mozilla.org one. Now I think that I should have submitted this to dropline.net instead of mozilla.org. But, on the other hand, Rudolf Vetschera notices this problem under Mozilla 1.2.1/Windows...
This bug shows up again in Phoenix 0.6. Version details: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030422 Firebird™ Browser/0.6 As you can see, I'm running this on Windows 2000, not Linux. The URLs I found this bug for, are http://www.mro.com/corporate/pdf/sam_wp.pdf and http://www.mro.com/corporate/pdf/MX5technology.pdf The same URLs work on IE, so it's not a problem with the server. I was thinking this should be opened as a new bug against the Phoenix product, but decided to wait until someone concurred.
Some funny behaviour. I just checked the links, and they both work on Mozilla 1.4b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030422 After I opened the http://www.mro.com/corporate/pdf/sam_wp.pdf URL in mozilla 1.4b, I came back to Phoenix (I have both browsers open on my PC at the same time, installed in separate directories), changed the theme from "Nautilus 1.0" to the default theme. Then I tried the URLs again. http://www.mro.com/corporate/pdf/sam_wp.pdf now worked in Phoenix! http://www.mro.com/corporate/pdf/MX5technology.pdf however, still gave me Bad request Your browser sent a query this server could not understand. So I went back to Mozilla, and typed the URL http://www.mro.com/corporate/pdf/MX5technology.pdf (I had not done this yet) This loaded fine. I then tried the same in but still got a Phoenix "Bad Request" message. Reverting to the "Nautilus 1.0" theme, doesn't change the behaviour. The sam_wp.pdf url, still works, and the MX5technology.pdf still doesn't work. Go Figure... I downloaded the nightly builds of both Mozilla and Phoenix, on the same day. In both cases I downloaded the win32.zip files. i.e. mozilla-win32.zip and phoenix-win32.zip. Are they both running against the same Gecko engine? Or has that changed for Phoenix? This talk of both browsers working on the same Mozilla trunk has me a little confused...
rajesh: Both links WFM in yesterday's Firebird nightly (with PhoenixClassic theme) on GNU/Linux. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030424 Mozilla Firebird/0.6
Just downloaded Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030424 Mozilla Firebird/0.6 The URLs work for me too. So what's the "diff" between the trunk on both days?
The UA string is different (not escaped TM sign in Phoenix)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.