Closed Bug 299181 Opened 20 years ago Closed 9 years ago

bad header showing in browser window -- http 1.1 incompatibility with cached requests

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
1.7 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: awinters, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

In a continuing effort to provide enterprise level tools to our clients,
Omniture has written Sitecatalyst to be fully compatible with Mozilla browsers.
 It has come to our attention that there is an intermittent problem for our
clients with a known http 1.1 bug in Mozilla.  Please see the following link
which refers to what we believe to be a related issue.  

http://weblogs.mozillazine.org/asa/archives/004370.html

The following is text taken from our testing environment showing the error that
occurs, where header information is displayed in the browser:

HTTP/1.1 200 OK Date: Wed, 29 Jun 2005 20:49:52 GMT Server: Apache/1.3.26 (Unix)
mod_ssl/2.8.9 OpenSSL/0.9.6e xserver: www192 Set-Cookie:
sc_user_settings=deleted; expires=Tue, 29-Jun-04 20:50:01 GMT; path=/;
domain=.omniture.com Set-Cookie:
sc_user_settings=qhlp%3D1%2Adet%3D1%2Aiav%3D1%2Afcst%3D1%2Amnu%3D0%2Amtrc%3D1%2Afrmt%3D1%2Aflsh_en%3D1%2Aapic%3D1%2Awkend%3D1%2Aforce_width%3D1%2Aexcel_intro%3D0;
expires=Wed, 10-Aug-05 12:50:02 GMT; path=/; domain=.omniture.com Keep-Alive:
timeout=15, max=86 Connection: Keep-Alive Transfer-Encoding: chunked
Content-Type: text/html daf
 
In our efforts to understand the issue we set the following in the http.conf on
our apache server:

BrowserMatch "Mozilla/5" downgrade-1.0 force-response-1.0

The problem was then no longer reproducible leading us to believe it is an http
1.1 incompatibility with Mozilla.  The primary differences in http 1.1 is its
ability to keep alive a persistent connection between the server and the
browser, and the compression of the data stream being transferred.  We notice
the error occurs when returning to a report, which suggests it could be an issue
dealing with cached pages.  The following is a quote from w3.org which may
address a possible hang up that Mozilla is having with http 1.1

To improve the perceived response time, a browser needs to learn basic size
information of each object in a page (required for page layout) as soon as
possible. The first bytes typically contain the image size. To achieve better
concurrency and retrieve the first few bytes of embedded links while still
receiving the bytes for the master document, HTTP/1.0 browsers usually use
multiple TCP connections. We believe by using range requests HTTP/1.1 clients
can achieve similar or better results over a single connection. 
HTTP /1.1 defines as part of the standard (and most current HTTP/1.0 servers
already implement) byte range facilities that allow a client to perform partial
retrieval of objects. The initial intent of range requests was to allow caching
proxy to finish interrupted transfers by requesting only the bytes of the
document they currently do not hold in their cache. 
To solve the problem that browsers need the size of embedded objects, we believe
that the natural revalidation request for HTTP/1.1 will combine both cache
validation headers and an If-Range request header, to prevent large objects from
monopolizing the connection to the server over its connection. The range
requested should be large enough to usually return any embedded metadata for the
object for the common data types. This capability of HTTP/1.1 is implicit in its
caching and range request design. 
When a browser revisits a page, it has a very good idea what the type of any
embedded object is likely to be, and can therefore both make a validation
request and also simultaneously request the metadata of the embedded object if
there has been any change. The metadata is much more valuable than the embedded
image data. Subsequently, the browser might generate requests for the rest of
the object, or for enough of each object to allow for progressive display of
image data types (e.g. progressive PNG, GIF or JPEG images), or to multiplex
between multiple large images on the page. We call this style of use of HTTP/1.1
"poor man's multiplexing." 
We believe cache validation combined with range requests will likely become a
very common idiom of HTTP/1.1. 


This issue has become a top priority for Omniture as many of our clients are
very high profile and they wish to access our tool with Mozilla.  We would like
to extend a hand of assistance in finding a final solution to this problem.  

Thank you,
John Vandermay
VP Engineering
Omniture

Reproducible: Always

Steps to Reproduce:
1. Load a page with pipelined data, served from a web server using http 1.1.
2. Reload the now-cached page several times.
3. See the garbage header text in the browser.

We can reproduce this everytime, but it does not always occur on the the first
refresh.

Actual Results:  
We see the following header text in the browser content window:
HTTP/1.1 200 OK Date: Wed, 29 Jun 2005 20:49:52 GMT Server: Apache/1.3.26 (Unix)
mod_ssl/2.8.9 OpenSSL/0.9.6e xserver: www192 Set-Cookie:
sc_user_settings=deleted; expires=Tue, 29-Jun-04 20:50:01 GMT; path=/;
domain=.omniture.com Set-Cookie:
sc_user_settings=qhlp%3D1%2Adet%3D1%2Aiav%3D1%2Afcst%3D1%2Amnu%3D0%2Amtrc%3D1%2Afrmt%3D1%2Aflsh_en%3D1%2Aapic%3D1%2Awkend%3D1%2Aforce_width%3D1%2Aexcel_intro%3D0;
expires=Wed, 10-Aug-05 12:50:02 GMT; path=/; domain=.omniture.com Keep-Alive:
timeout=15, max=86 Connection: Keep-Alive Transfer-Encoding: chunked
Content-Type: text/html daf

 


Expected Results:  
We shouldn't see the header text and the header should have been handled correctly.
Assignee: nobody → darin
Component: General → Networking: HTTP
Product: Firefox → Core
Version: unspecified → Trunk
This issue was resolved in v0.10. To do a test case and confirm your "trouble"
we need the link to the page you tested with. Please post a link as an aditional
comment or upload an attachment. Thankyou for your cooperation.
Please retest this with a firefox 1.0.1 or later browser which contains many
fixes beyond the 0.10 you reported this against. It would also be extremely
useful to know if any of the last year's worth of network library changes that
are in the Deer Park Alphas (next version of Firefox) still exhibit this behavior.

Do you have a server we could test against? We've found many pipelining issues
to be strongly dependent on the particular server implementation due to
ambiguities in the spec or incomplete implementation (as indicated in that blog
post you link to).

You link to a blog post about pipelining, but pipelining still defaults to off
in Firefox. Are you seeing this with a stock Firefox installation, or have you
turned on the pipelining features? Again, a server to test against would help
out here.

Leaving unconfirmed while awaiting above answers
Version: Trunk → 1.7 Branch
(In reply to comment #1)
> This issue was resolved in v0.10.

Have a bug number?

(In reply to comment #3)
> (In reply to comment #1)
> > This issue was resolved in v0.10.
> 
> Have a bug number?
> 

Not on me.

I was distracted, the issue in question may or may not have been resolved already

(In reply to comment #5)

It doesn't appear to be fixed.  This is what I see using Firefox 1.0.4:

HTTP/1.1 200 OK Date: Thu, 30 Jun 2005 00:28:36 GMT Server: Apache/1.3.26 (Unix)
mod_ssl/2.8.9 OpenSSL/0.9.6e xserver: www169 Set-Cookie:
sc_user_settings=deleted; expires=Wed, 30-Jun-04 00:28:35 GMT; path=/;
domain=.omniture.com Set-Cookie:
sc_user_settings=qhlp%3D1%2Adet%3D1%2Aiav%3D1%2Afcst%3D1%2Amnu%3D0%2Amtrc%3D1%2Afrmt%3D0%2Aflsh_en%3D1%2Aapic%3D1%2Awkend%3D1%2Aforce_width%3D1%2Aexcel_intro%3D0;
expires=Wed, 10-Aug-05 16:28:36 GMT; path=/; domain=.omniture.com Keep-Alive:
timeout=15, max=92 Connection: Keep-Alive Transfer-Encoding: chunked
Content-Type: text/html d7f

Answers to questions:
1. Pipelining on or off? I'm using a stock installation, so off.
2. I haven't tried it using Deer Park alpha.  I'll install it and report my
findings.
3. Link to a URL?  Unfortunately, I can't give that out without compromising our
customers' data or our IP (from competitors).  I can set up a WebEx conference
call and walk you through it.  Let's take this discussion off the forum.
4. You mention server configuration--what apache information will be helpful? 
With pipelining off, that may not be the issue.

(In reply to comment #6)
I still see it in Deer Park Alpha (May 31, 2005 build).
(In reply to comment #2)

Did my answers at the bottom help?  I can set up an account, give a URL and
steps to reproduce the behavior, but I'd like to keep that information private.
 May I email this information to each on the cc list?

Omniture is willing to negotiate pay for someone to fix this.  This bug in
Mozilla is causing significant pain for our large clients who have a standard
policy to use Mozilla-based browsers.  They've seen the issue on other sites
than our own.  Any help toward a resolution on this bug is appreciated.

Thank you,
Alan

[from reply #6 & #7]

It is still broken in Deer Park Alpha and Firefox 1.0.4. 

Answers to questions:
1. Pipelining on or off? I'm using a stock installation, so off.
2. I haven't tried it using Deer Park alpha.  I'll install it and report my
findings.
3. Link to a URL?  Unfortunately, I can't give that out without compromising our
customers' data or our IP (from competitors).  I can set up a WebEx conference
call and walk you through it.  Let's take this discussion off the forum.  
4. You mention server configuration--what apache information will be helpful? 
With pipelining off, that may not be the issue.
I am one of the clients that Alan refers to (Sun Microsystems).  Sun uses
Mozilla as our corporate default browser.  This bug causes great difficultly
with Omniture reports rendering correctly.  In addition, when the bug happens
other features in the Omniture reporting tool hang and a page reload is
necessary to make the page work.

Not only is it a nuisance but somewhat embarrassing as Sun execs run Omniture on
Mozilla and experience this problem as well.  

Please let me know if there's anything I can do to help.

I see this on Mozilla and Firefox.  Below are details of our environments.

Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050606 Firefox/1.0.4

Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214


This looks like a bad server to me.  The server appears to be sending 3 bytes of
garbage before sending the response headers.  This causes Firefox to treat the
response as a HTTP/0.9 response, which is why the headers appear in the browser
window.  I think you should fix the server.

I see a connection being reused to serve a HTML document.  Previously, the
connection was used to serve a JPEG image that was 23718 bytes long:
URL=/sc12/reports/chart.php?id=CPRMF_ZPCd_mpuC&s=www455&type=GIF

Firefox appears to have consumed exactly 23718 bytes from the connection before
inserting it back into its keep-alive pool.  Then it goes to reuse the
connection to load:
URL=/sc12/reports/page_details.html?ssSession=XXX

At this point the response from the server includes three random bytes that are
not "HTT" as they should be.

This bug is technically invalid.  We could probably work around the bad server,
but since you probably care about existing Firefox deployments, my
recommendation to you would be to fix the server if you can possibly do so.
Darin, should we just resolve this as invalid per comment 10?
(In reply to comment #11)
> Darin, should we just resolve this as invalid per comment 10?
> 

I'd rather it be left unconfirmed for right now.  We're not seeing the same results.  We can duplicate this with http and have viewed the packets and don't see anything extraneous.  We'd like to get the detail you need to see exactly what's going on.  Thanks.
I'm getting something that looks similar to this problem, whereby headers are showing in the page.

The pages are on (not just that one but any of the menu links): http://www.aub-unison.org.uk/index.cfm?section=2

And the screenshot showing the problem is:
http://www.seajays.org.uk/images/errorscreenshot.png

Using Firefox: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8) Gecko/20051107 Firefox/1.5

If you refresh sometimes it appears and other times it doesn't.
Actually I should clarify the statement above.  Refreshing the page with the 'refresh' button does not display the error, however clicking one of the menu links on the page (the top menu buttons), and then clicking the menu link back to the original page again, does show the headers in the content again, although this is then intermittent.
A little bit more as well - it definitely seems to be connected with HTTP/1.1 and cacheing (as OP stated).

At work, I connect to the internet via a proxy server, which converts all requests/responses to HTTP/1.0 - and the problem never appears in Firefox there.

However, accessing the same site (with the same version of Firefox) from home, where there is no intervening proxy, and everything is HTTP/1.1 (confirmed with liveHTTPheaders plugin), requests/responses generated seem to cause this intermittent problem when viewing pages - specifically when going back to pages just viewed, which I assume are then coming from the cache.  

Clicking the same link again and again, brings up the error intermittently (6 out of 20 clicks just now).
(In reply to comment #12)
> We can duplicate this with http
> We'd like to get the detail

Alan Winters, I think looking HTTP level flow is usualy the first step for this kind of analysis.
 (1) HTTP protocol log by NSPR logging
     See http://www.mozilla.org/projects/netlib/http/http-debugging.html   
 (2) HTTP Header log by LiveHTTPHeaders
     See http://livehttpheaders.mozdev.org/index.html
(2) is easier to view HTTP header flow only, but (1) is better for problem analysis.

By the way, who puts "daf" or "d7f" just after "Content-Type: text/html"?
It looks same kind of data as "3 bytes of garbage" after image data pointed by Darin Fisher in #10.
(In reply to comment #16)
> By the way, who puts "daf" or "d7f" just after "Content-Type: text/html"?
> It looks same kind of data as "3 bytes of garbage" after image data pointed by
> Darin Fisher in #10.

That is most likely the header for the first chunk of the content, as it is using Transfer-Encoding: chunked (which sends using a number chunks, each with their own little size prefix in hex).
> Darin, should we just resolve this as invalid per comment 10?

no, i'd rather not.  if IE handles this junk properly, then we should try to find a way to handle it too.
Any word on this bug being looked at?  My site still exhibits the same symptoms as described earlier - so the problem has not gone away from the website end, and the problem is still visible if anyone wants to take a look at it and see it for themselves.
QA Contact: general → networking.http
-> reassign to default owner
Assignee: darin.moz → nobody
Is this still a problem ?
comment 10
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.