Return-Path: 
 <cocoon-dev-return-33805-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 93110 invoked by uid 500); 6 Dec 2002 00:10:33 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 93097 invoked from network); 6 Dec 2002 00:10:32 -0000
Sender: sam
Message-ID: <3DEFECC1.D675E227@atnet.net.au>
Date: Fri, 06 Dec 2002 10:18:09 +1000
From: sam <samc@atnet.net.au>
Organization: Golden Orb Technologies
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: ResourceReader and pdf
References: <GJEJLHBKHOLBEIGBEGAIIENFCLAA.lars.steiger@buzzard.ch>
 <3DEDC2ED.3050703@gmx.de> <3DEE6C9E.2050701@yahoo.de>
 <3DEEA542.5000209@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Hi folks,
    we had similar problems with using ResourceReader with serving static PDF
and flash (SWF) on both versions 2.0.1 and the 2.1-dev cvs that we are now
experimenting with.

    At the time, as far as I could tell this was because of IE5+ have broken
support for the Vary header, which is output by Tomcat in this instance. Apache
doesn't do this for static PDFs and SWFs so it is not a problem if served
statically from there.

    In our environment, we use Apache and connect this to Tomcat with mod/jk2.
Because we want to protect the documents with our servlet based security
mechanism, we had to host these on Tomcat. I found using the following
browsermatch directives in apache httpd.conf will stop the strange behaviours
with these binary file types:

--snip---
.
.
.
<IfModule mod_setenvif.c>
    BrowserMatch "Mozilla/2" nokeepalive
    BrowserMatch "MSIE [1-4]" nokeepalive ssl-unclean-shutdown downgrade-1.0
force-response-1.0 force-no-vary
    BrowserMatch "MSIE [5-9]" ssl-unclean-shutdown force-no-vary
.
.
.
--snip---

good luck,
Sam

Joerg Heinicke wrote:

> >> We have the same problem with Cocoon 2.0.1. Do you have a current
> >> version? First tests with 2.0.3 were okay, even if the code, you
> >> mention, has not changed. But maybe the tests only were okay by accident?
> >
> > Maybe. AFAIK the dependency on the correct content length
> > for displaying PDF is a IEx specific problem, other browsers
> > may work without it.
>
> The people, who tested it, said, that it was not the IE problem, but
> browser independent. And the download in the different browsers gave
> different file sizes at the end.
> We deliver the PDFs now simply via Apache, no Cocoon.
>
> Joerg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org