Johann Mattsson wrote:
On a weblogic server we transform XML documents to FO via XSLT, and render it
to PDF, all within COCOON. The PDF is then sent to the browser where Acrobat
reader opens. However, occasionaly some problem obviousley occurs, resulting
in no error messages, but the browser displays the PDF code instead of
starting Acrobat reader.
If I manipulate the "faulty" source XML slightly, for example change a digit
or something (pure XML, it isnt the FO code or anything), the browser nicely
opens the resulting PDF document...
It seems the browser can't interpret the content type and falls back
to text/plain. Changing the XML source causes Cocoon to regenerate and
resend the PDF instead of telling the browser that nothing changed,
causing it to use the cached content (including the wrong MIME type).
I've seen this kind of behaviour with other browsers and content types
too. I have no idea whether these are strange network glitches, server
hickups or problems with the Windows TCP stack. If you have a
reasonably high chance to reproduce it, monior the network traffic both
from some other machine (preferebly not Windows) and the machine with
the browser, and check whether the "content-type: application/pdf"
header comes unmangled over the connection.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
