Closed Bug 196835 Opened 22 years ago Closed 22 years ago

Redirect to a gzipped page is broken in current release candidate. Works in Mozilla 1.3b.

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
Other Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.3final

People

(Reporter: maik.jablonski, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030307 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030307 Select another item in the box right on the top of page (something like "Seite 75"). The server sends a redirect as response to a gzipped page. This is not displayed correctly. The whole thing works without problems with Mozilla 1.3b. Reproducible: Always Steps to Reproduce: 1. Select "Seite 75" (or another one) in the box right above of the page. 2. 3. Actual Results: The page is broken and mixed up with html-headers, gzipped contents etc. Expected Results: A correct display of the page as it worked in Mozilla 1.3b
Keywords: regression
I also noticed that more often and recently on http://linuxfr.org/ which uses mod_gzip. Perhaps bug 176222 got more visible because of recent changes.
Setting milestone. But wfm on build of 20030306 on XP Pro SP1. If someone can confirm this bug, I think the blocking 1.3 flag should be requested.
Target Milestone: --- → mozilla1.3final
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030310
Works For Me: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030305 That's a WFM on each of the Mar 5, Mar 6, and Mar 10 builds running on Win2K/WinXP on either the 1.3 branch or the trunk. As original report was under Linux, I'm thinking this may be platform-specific (as currently marked). Bug 176222 shows the platform as All. I haven't read the whole history for that bug, but I assume it is Platform: All for a reason. At the very least, it was confirmed on a bunch of Win2K/XP systems. As such, I doubt this is a relative of Bug 176222. Quick question: Reporter, how clean was your install of this build? Clean Mozilla folder? Clean profile? Can anyone verify this under Linux?
WFM with 20030310 build, but I'm also on Windows. setting the blocker flag anyway - someone else needs to try this on Linux...
Flags: blocking1.3?
Version: Trunk → Other Branch
by popular demand i booted my Linux Mandrake 9.1 RC2 with Moz 2003031008. and it's a WFM. One thing : this is a trunk build, and not a 1.3 branch? Summary specifically states branch build...will try that next
Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030310 pages seite 75 etc all work for me.No gzipped contents anywere. Sorry, can't reproduce
well I think I'll take bug that 1.3? flag in that case. reporter (Maik) - are you using a proxy of any kind? do you have pipelining enabled? if you create a new profile to test with, does this still happen? thanks
Flags: blocking1.3?
I see the bad behaviour. My connections are transparently forced through Squid proxy. The problem appears if you have pipelining enabled. If I disable pipelining, works ok. But with pipelining enabled, content gets disturbed.
... and I'm using 1.3 build 20030309.
Tried the whole thing with same Mozilla-Build from my Debian-Linux over DSL at home. No problems at all. At work (where I encountered the problem) I use RedHat 8. I'll will test a fresh install there tomorrow to reproduce the problem.
ah... if it happens only with pipelining, that probably means this is related to or a duplicate of bug 192546, bug 140530. not 100% sure, so I won't mark it as a dupe just yet...
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
Depends on: 140530
QA Contact: asa → httpqa
Whiteboard: [pipelining]
my guess is that all these bugs are the same bug. there's simply some bug in the pipelining code that causes data corruption.
WFM Have Pipelining and HTTP1.1 enabled and am behind a Squid proxy. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030309 on Mandrake 9.0/1
I've tested it again with a fresh profile under RedHat 8.0 and can reproduce the error. Pipelining is disabled. I'm going to create a "cleaner" test-case for this issue...
I've encountered the same problem for another gzipped (apache) site (www.dzug.org). It happens only from time to time, but it's there. Mozilla 1.3b doesn't have this problem...
maik: thanks for the additional information... are you saying that you can only reproduce this bug with recent 1.3 branch builds?
Whiteboard: [pipelining]
There error does definitively not occur with Mozilla 1.3b. It is constantly reproducable with - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030307 and - Mozilla 1.4a (latest build) on Redhat 8.0 (over 100mbit-Network). It does not occur with Debian Woody via DSL. Strange, very strange...
Started experiencing this on LAN sites that are using mod_gzip when I upgraded from 1.3b to 1.3final on RedHat 8.0 (xft RPM build). Seen same problem with 1.3final on Windows XP as well, while visiting same sites. Seems to occur randomly.
ok, is anyone seeing this with a build later than 2003-03-25 (1.4alpha, for example)? a fix for similar problems was checked in on 24th March, and this may or may not be the same bug...
No longer see the problem with a current linux build (2003040305), so it is possible the issue has been resolved. It looks like the problem was that body of a redirect response was prepended to the destination content (headers and body).
WFM with a current Windows trunk build. resolving WFM based on previous comments. If someone can reproduce this with a recent build, please reopen and comment with details. thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.