sorry, that i respond that late. but better late, than never ;)
FYI: i'm using cocoon2.0.2 at the moment.
i don't know really how deep the "pdf/ResourceReader" problem is connected
to a specific browser. the only thing that i detect was, that after i
overrode the method "shouldSetContentLength" on
"org.apache.cocoon.reading.ResourceReader" as below:
/**
* Test if the component wants to set the content length
*/
public boolean shouldSetContentLength() {
return true;
}
the problem (messagebox on browser side: "The file is damaged and could not
be repaired.") disappeared. the overriding returns true instead of false
(extendend by AbstractReader). i don't understand the CachingStreamPipeline
or AbstractStreamPipeline that much, but there is a decision which
definitely react in different ways for setting the content length to the
environment. so i'm in doubt if it is enought to set the content length on
the response header.
greetings,
lars
ps: by the way we also released lately a live site fully based on
cocoon,mysql and tomcat. if you wan't the proof that the ResourceReader
bugfix mentioned above works (hopefully :)) - have a look at
http://www.warnerbros.ch/pdf/orgchart-dec02.pdf
> -----Ursprungliche Nachricht-----
> Von: Stuart Roebuck [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 5. Dezember 2002 11:30
> An: [EMAIL PROTECTED]
> Betreff: Re: ResourceReader and pdf
>
>
> If this is an issue with 2.0.4 then I would be concerned. It was fixed
> for 2.0.3 - at least certainly for the version we have on our active
> server.
>
> Delivering with Apache is fine until you need to restrict access using
> Cocoon based user controls.
>
> To summarize my understanding of the issues with PDFs...
>
> * If your end users don't use any PDF plugin then everything will work
> fine.
>
> * Certain Adobe PDF plugins combined with certain browsers require a
> correct file size to be returned in order for download to work. There
> are a lot of people out there with IE, PDF Plugin combinations that
> experience this issue - so it is a *real* issue if it doesn't work.
>
> Here is the closed bug which covered this last time:
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7156>
>
> Stuart.
>
> On Thursday, December 5, 2002, at 01:00 am, 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
> (Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
> 65AF
> ------------------------------------------------------------------------
> -
> Stuart Roebuck
> [EMAIL PROTECTED]
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
> <http://www.adolos.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
