|
PDF problems in IE
Hi all,
Has anyone noticed an issue where only IE users, when they click on PDF
documents, get a message that says that the PDF document is damaged?
This doesn't happen for Firefox or other browsers. I did some
searching in the Jetty support lists to see if anyone was experiencing
something similar and I found this:
http://news.gmane.org/find-root.php?
message_id=%3cdcoqv0%24j69%241%40sea.gmane.org%3e
The person explains a solution for fixing this, but I don't see where
this file is in the Jetty installation with Lenya. Has anyone else had
this problem, and does anyone know what I can do to fix it? I have
some pretty confused and upset people calling me every other day on
this one... :)
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
On Thu, 2005-08-25 at 10:08 -0400, Jonathan Linczak wrote:
> Hi all,
>
> Has anyone noticed an issue where only IE users, when they click on PDF
> documents, get a message that says that the PDF document is damaged?
> This doesn't happen for Firefox or other browsers. I did some
> searching in the Jetty support lists to see if anyone was experiencing
> something similar and I found this:
>
> http://news.gmane.org/find-root.php?
> message_id=%3cdcoqv0%24j69%241%40sea.gmane.org%3e
Hi Jon,
It might have something to do with
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112496255207733&w=2The Acrobat Reader Browser-Plugin uses Range-Requests if the option
"Allow Fast Web View" is enabled. The MediaResourceReader of Cocoon does
not understand these requests.
You could try to disable the "Allow Fast Web View" option to see if this
is the problem.
But you said it works with Firefox, so maybe it's something else.
Can you give the exact error message?
hth,
Josias
>
> The person explains a solution for fixing this, but I don't see where
> this file is in the Jetty installation with Lenya. Has anyone else had
> this problem, and does anyone know what I can do to fix it? I have
> some pretty confused and upset people calling me every other day on
> this one... :)
>
> Jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Hi Josias, hi Jon, hi all,
We have this pb here too.
Some pdf cannot be readen by Explorer, but by Firefox.
It seems that PDFs created with PDF printers of word, PDFcreator; or
other printers show this problem.
PDFs created with Adobe Professionnal display correctly in Explorer.
I don't know how to fix this.
Regards. annie
Josias Thoeny a ?crit :
>On Thu, 2005-08-25 at 10:08 -0400, Jonathan Linczak wrote:
>
>
>>Hi all,
>>
>>Has anyone noticed an issue where only IE users, when they click on PDF
>>documents, get a message that says that the PDF document is damaged?
>>This doesn't happen for Firefox or other browsers. I did some
>>searching in the Jetty support lists to see if anyone was experiencing
>>something similar and I found this:
>>
>> http://news.gmane.org/find-root.php?
>>message_id=%3cdcoqv0%24j69%241%40sea.gmane.org%3e
>>
>>
>
>Hi Jon,
>
>It might have something to do with
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112496255207733&w=2>
>The Acrobat Reader Browser-Plugin uses Range-Requests if the option
>"Allow Fast Web View" is enabled. The MediaResourceReader of Cocoon does
>not understand these requests.
>You could try to disable the "Allow Fast Web View" option to see if this
>is the problem.
>
>But you said it works with Firefox, so maybe it's something else.
>Can you give the exact error message?
>
>hth,
>Josias
>
>
>
>>The person explains a solution for fixing this, but I don't see where
>>this file is in the Jetty installation with Lenya. Has anyone else had
>>this problem, and does anyone know what I can do to fix it? I have
>>some pretty confused and upset people calling me every other day on
>>this one... :)
>>
>>Jon
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@...
>>For additional commands, e-mail: user-help@...
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@...
>For additional commands, e-mail: user-help@...
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
On Aug 25, 2005, at 12:05 PM, Josias Thoeny wrote:
> On Thu, 2005-08-25 at 10:08 -0400, Jonathan Linczak wrote:
>> Hi all,
>>
>> Has anyone noticed an issue where only IE users, when they click on
>> PDF
>> documents, get a message that says that the PDF document is damaged?
>> This doesn't happen for Firefox or other browsers. I did some
>> searching in the Jetty support lists to see if anyone was experiencing
>> something similar and I found this:
>>
>> http://news.gmane.org/find-root.php?
>> message_id=%3cdcoqv0%24j69%241%40sea.gmane.org%3e
>
> Hi Jon,
>
> It might have something to do with
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112496255207733&w=2>
> The Acrobat Reader Browser-Plugin uses Range-Requests if the option
> "Allow Fast Web View" is enabled. The MediaResourceReader of Cocoon
> does
> not understand these requests.
> You could try to disable the "Allow Fast Web View" option to see if
> this
> is the problem.
>
> But you said it works with Firefox, so maybe it's something else.
> Can you give the exact error message?
>
> hth,
> Josias
Hi Josias,
Sorry for the late reply. I checked one file that I know we are having
problems with and it already does not have Fast Web View enabled, so
that can't be the issue. Again, this is only with IE when the user
clicks directly on the link and tries to load the PDF document in their
PDF reader plugin (Adobe Acrobat reader). All other browsers that I
know of work, and users of IE will work when they right-click on the
document and save to disk first before opening.
That link I gave had a solution and it dealt with changing some config
file in Jetty. I haven't been able to find this file in the Lenya
release, so I assume the version of Jetty that comes with Lenya is just
the binary with nothing to change. Can someone confirm this and then
know of a way to fix this problem? I can't believe no one else is
running into this problem besides me and Annie?! :)
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
On Wed, 2005-08-31 at 12:03 -0400, Jonathan Linczak wrote:
> On Aug 25, 2005, at 12:05 PM, Josias Thoeny wrote:
>
> > On Thu, 2005-08-25 at 10:08 -0400, Jonathan Linczak wrote:
> >> Hi all,
> >>
> >> Has anyone noticed an issue where only IE users, when they click on
> >> PDF
> >> documents, get a message that says that the PDF document is damaged?
> >> This doesn't happen for Firefox or other browsers. I did some
> >> searching in the Jetty support lists to see if anyone was experiencing
> >> something similar and I found this:
> >>
> >> http://news.gmane.org/find-root.php?
> >> message_id=%3cdcoqv0%24j69%241%40sea.gmane.org%3e
> >
> > Hi Jon,
> >
> > It might have something to do with
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112496255207733&w=2> >
> > The Acrobat Reader Browser-Plugin uses Range-Requests if the option
> > "Allow Fast Web View" is enabled. The MediaResourceReader of Cocoon
> > does
> > not understand these requests.
> > You could try to disable the "Allow Fast Web View" option to see if
> > this
> > is the problem.
> >
> > But you said it works with Firefox, so maybe it's something else.
> > Can you give the exact error message?
> >
> > hth,
> > Josias
>
>
> Hi Josias,
>
> Sorry for the late reply. I checked one file that I know we are having
> problems with and it already does not have Fast Web View enabled, so
> that can't be the issue. Again, this is only with IE when the user
> clicks directly on the link and tries to load the PDF document in their
> PDF reader plugin (Adobe Acrobat reader). All other browsers that I
> know of work, and users of IE will work when they right-click on the
> document and save to disk first before opening.
Hi Jon,
You mean the PDF file itself was not built with support for fast web
view?
I was talking about an option in the Adobe Acrobat Reader, which causes
the reader plugin not to try "fast web view" when downloading a file,
independent of the PDF file supporting it or not. But I don't know if it
makes a difference.
When you open the file in a different browser, does it use the plugin to
display the PDF file directly in the browser?
>
> That link I gave had a solution and it dealt with changing some config
> file in Jetty. I haven't been able to find this file in the Lenya
> release, so I assume the version of Jetty that comes with Lenya is just
> the binary with nothing to change. Can someone confirm this and then
> know of a way to fix this problem? I can't believe no one else is
> running into this problem besides me and Annie?! :)
Do you mean
"Bingo! When I set acceptRanges to false in webdefault.xml, the problem
goes away." ?
The webdefaults.xml file is located at
[LENYA_HOME]/tools/jetty/conf/webdefaults.xml
That thread talks about serving byte ranges. This is what the "fast web
view" option does, it uses byte range requests to download only parts of
the PDF file.
So disabling this option in the reader should have the same effect as
disabling it in the server.
If nothing else helps, you could try a different servlet container, like
Tomcat, to see if it's a jetty problem.
Josias
>
> Jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
>> Hi Josias,
>>
>> Sorry for the late reply. I checked one file that I know we are
>> having
>> problems with and it already does not have Fast Web View enabled, so
>> that can't be the issue. Again, this is only with IE when the user
>> clicks directly on the link and tries to load the PDF document in
>> their
>> PDF reader plugin (Adobe Acrobat reader). All other browsers that I
>> know of work, and users of IE will work when they right-click on the
>> document and save to disk first before opening.
>
> Hi Jon,
>
> You mean the PDF file itself was not built with support for fast web
> view?
> I was talking about an option in the Adobe Acrobat Reader, which causes
> the reader plugin not to try "fast web view" when downloading a file,
> independent of the PDF file supporting it or not. But I don't know if
> it
> makes a difference.
>
> When you open the file in a different browser, does it use the plugin
> to
> display the PDF file directly in the browser?
Yeah, that's what I meant, but I didn't try the other way around -
checking the browser plug-in. Where exactly do I change this setting
in the reader itself? Using IE on Windows, which is the only
combination that seems to be having this problem, clicking directly on
the link causes the text: "The file is damaged and could not be
repaired.". When I open up (on the same computer) Firefox and click on
the same link, it loads just fine in the plugin for Firefox. But it's
strange - I had a Windows user that opened up IE and was able to see
the file when having just an Acrobat 5 reader software. Reader 6 and 7
seem to not like it. And when the computer has the full Acrobat
version, it loads fine as well.
>> That link I gave had a solution and it dealt with changing some config
>> file in Jetty. I haven't been able to find this file in the Lenya
>> release, so I assume the version of Jetty that comes with Lenya is
>> just
>> the binary with nothing to change. Can someone confirm this and then
>> know of a way to fix this problem? I can't believe no one else is
>> running into this problem besides me and Annie?! :)
>
> Do you mean
> "Bingo! When I set acceptRanges to false in webdefault.xml, the problem
> goes away." ?
>
> The webdefaults.xml file is located at
> [LENYA_HOME]/tools/jetty/conf/webdefaults.xml
>
> That thread talks about serving byte ranges. This is what the "fast web
> view" option does, it uses byte range requests to download only parts
> of
> the PDF file.
> So disabling this option in the reader should have the same effect as
> disabling it in the server.
>
> If nothing else helps, you could try a different servlet container,
> like
> Tomcat, to see if it's a jetty problem.
>
> Josias
Yup, that's what I was referring to. I actually made the change to our
server and it doesn't seem to make a difference. But while I'd like to
test with Tomcat, there's no way I'm switching back after the good luck
I've been having with Jetty. :) Here's another document that has some
discussion on the issue, but no real concrete answers for me, unless
you see something useful:
http://72.14.207.104/search?q=cache:JUZXj0O4yXAJ:www.newsarch.com/
archive/mailinglist/comp/java/jetty/general/
msg00360.html+Jetty+IE+%22The+file+is+damaged+and+could+not+be+repaired.
%22&hl=en&client=firefox-a. I'll see if the test instance of Tomcat
serving the same PDF document solves the issue and post a response
here.
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Jonathan Linczak wrote:
> Yup, that's what I was referring to. I actually made the change to
> our server and it doesn't seem to make a difference. But while I'd
> like to test with Tomcat, there's no way I'm switching back after the
> good luck I've been having with Jetty. :) Here's another document
> that has some discussion on the issue, but no real concrete answers
> for me, unless you see something useful:
> http://72.14.207.104/search?q=cache:JUZXj0O4yXAJ:www.newsarch.com/
> archive/mailinglist/comp/java/jetty/general/
> msg00360.html+Jetty+IE+%22The+file+is+damaged+and+could+not+be+repaired.
> %22&hl=en&client=firefox-a. I'll see if the test instance of Tomcat
> serving the same PDF document solves the issue and post a response
> here.
"If the request for the PDF document is being handled by MSIE it appears
to start downloading the content, then decides that it really should
have invoked the PDF plug-in. It then just 'pulls the plug' on that
request-response pair and passes control to the plug-in, which has to
start again. This may explain some of the broken connections."
i had this problem in a customer project, and when i debugged it with
http headers, ie would request pdf differently than ff. in my case, i
was able to so solve the problems by playing with the expiry / cache
headers that get sent along (in the sitemap). sorry i do not recall all
the details, maybe it was this:
http://www.planetpdf.com/forumarchive/55559.asp---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
On Aug 31, 2005, at 1:36 PM, Gregor J. Rothfuss wrote:
> Jonathan Linczak wrote:
>
>> Yup, that's what I was referring to. I actually made the change to
>> our server and it doesn't seem to make a difference. But while I'd
>> like to test with Tomcat, there's no way I'm switching back after the
>> good luck I've been having with Jetty. :) Here's another document
>> that has some discussion on the issue, but no real concrete answers
>> for me, unless you see something useful:
>> http://72.14.207.104/search?q=cache:JUZXj0O4yXAJ:www.newsarch.com/
>> archive/mailinglist/comp/java/jetty/general/
>> msg00360.html+Jetty+IE+%22The+file+is+damaged+and+could+not+be+repaire
>> d.
>> %22&hl=en&client=firefox-a. I'll see if the test instance of Tomcat
>> serving the same PDF document solves the issue and post a response
>> here.
>
> "If the request for the PDF document is being handled by MSIE it
> appears to start downloading the content, then decides that it really
> should have invoked the PDF plug-in. It then just 'pulls the plug' on
> that request-response pair and passes control to the plug-in, which
> has to start again. This may explain some of the broken connections."
>
> i had this problem in a customer project, and when i debugged it with
> http headers, ie would request pdf differently than ff. in my case, i
> was able to so solve the problems by playing with the expiry / cache
> headers that get sent along (in the sitemap). sorry i do not recall all
> the details, maybe it was this:
>
> http://www.planetpdf.com/forumarchive/55559.aspWell I was able to do a quick test using a default setup of Tomcat and
the Acrobat plug-in loads the page just fine in IE/Win. So it's
definitely down to some setup in Jetty/Cocoon/Lenya that's causing the
problem. Gregor, how does one set these headers in the sitemap? And
do you mean the publication-sitemap.xmap in each pub or the overall
sitemap? Did you create a pipeline that made this work for all PDF
files?:
<map:pipeline>
<map:match pattern="**/*.pdf">
... stuff in here ...
</map:match>
</map:pipeline>
Any help on this one is hugely appreciated!!! :)
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Jonathan Linczak wrote:
> Well I was able to do a quick test using a default setup of Tomcat and
> the Acrobat plug-in loads the page just fine in IE/Win. So it's
> definitely down to some setup in Jetty/Cocoon/Lenya that's causing the
> problem. Gregor, how does one set these headers in the sitemap? And
> do you mean the publication-sitemap.xmap in each pub or the overall
> sitemap? Did you create a pipeline that made this work for all PDF
> files?:
>
<map:pipeline type="noncaching">
<map:parameter name="expires" value="access"/>
<map:match pattern="**/*.pdf">
... stuff in here ...
</map:match>
should take care of the cache expiry headers
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
> Jonathan Linczak wrote:
>
>> Yup, that's what I was referring to. I actually made the change to
>> our server and it doesn't seem to make a difference. But while I'd
>> like to test with Tomcat, there's no way I'm switching back after the
>> good luck I've been having with Jetty. :) Here's another document
>> that has some discussion on the issue, but no real concrete answers
>> for me, unless you see something useful:
>> http://72.14.207.104/search?q=cache:JUZXj0O4yXAJ:www.newsarch.com/>> archive/mailinglist/comp/java/jetty/general/
>> msg00360.html+Jetty+IE+%22The+file+is+damaged+and+could+not+be+repaired.
>> %22&hl=en&client=firefox-a. I'll see if the test instance of Tomcat
>> serving the same PDF document solves the issue and post a response
>> here.
>
> "If the request for the PDF document is being handled by MSIE it appears
> to start downloading the content, then decides that it really should
> have invoked the PDF plug-in. It then just 'pulls the plug' on that
> request-response pair and passes control to the plug-in, which has to
> start again. This may explain some of the broken connections."
>
> i had this problem in a customer project, and when i debugged it with
> http headers, ie would request pdf differently than ff. in my case, i
> was able to so solve the problems by playing with the expiry / cache
> headers that get sent along (in the sitemap). sorry i do not recall all
> the details, maybe it was this:
>
> http://www.planetpdf.com/forumarchive/55559.aspI think IE sometimes needs to save a document in a temporary folder before
it can be opened with a plugin. Now, if the reponse header tells IE that
the document cannot be cached, it cannot be written to the temp folder,
and IE reports an error.
See also http://support.microsoft.com/default.aspx?scid=kb;en-us;317208,
(only about office documents, though).
To debug the http headers, you could use a tool like Ethereal, or turn on
http request logging in the servlet container (in Tomcat, enable the
RequestDumperValve in server.xml).
Josias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Josias Thoeny wrote:
> To debug the http headers, you could use a tool like Ethereal, or turn on
> http request logging in the servlet container (in Tomcat, enable the
> RequestDumperValve in server.xml).
much easier: http://www.blunck.info/iehttpheaders.html---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
>>> Hi Josias,
>>>
>>> Sorry for the late reply. I checked one file that I know we are
>>> having
>>> problems with and it already does not have Fast Web View enabled, so
>>> that can't be the issue. Again, this is only with IE when the user
>>> clicks directly on the link and tries to load the PDF document in
>>> their
>>> PDF reader plugin (Adobe Acrobat reader). All other browsers that I
>>> know of work, and users of IE will work when they right-click on the
>>> document and save to disk first before opening.
>>
>> Hi Jon,
>>
>> You mean the PDF file itself was not built with support for fast web
>> view?
>> I was talking about an option in the Adobe Acrobat Reader, which causes
>> the reader plugin not to try "fast web view" when downloading a file,
>> independent of the PDF file supporting it or not. But I don't know if
>> it
>> makes a difference.
>>
>> When you open the file in a different browser, does it use the plugin
>> to
>> display the PDF file directly in the browser?
>
>
> Yeah, that's what I meant, but I didn't try the other way around -
> checking the browser plug-in. Where exactly do I change this setting
> in the reader itself?
To change this option, open the Acrobat Reader (not just the browser
plugin), go to edit -> preferences -> internet -> allow fast web view
(I hope I remember this correctly)
Your problem may be caused by something else, but this option is easy to
try ;-)
Josias
> Using IE on Windows, which is the only
> combination that seems to be having this problem, clicking directly on
> the link causes the text: "The file is damaged and could not be
> repaired.". When I open up (on the same computer) Firefox and click on
> the same link, it loads just fine in the plugin for Firefox. But it's
> strange - I had a Windows user that opened up IE and was able to see
> the file when having just an Acrobat 5 reader software. Reader 6 and 7
> seem to not like it. And when the computer has the full Acrobat
> version, it loads fine as well.
>
>
>>> That link I gave had a solution and it dealt with changing some config
>>> file in Jetty. I haven't been able to find this file in the Lenya
>>> release, so I assume the version of Jetty that comes with Lenya is
>>> just
>>> the binary with nothing to change. Can someone confirm this and then
>>> know of a way to fix this problem? I can't believe no one else is
>>> running into this problem besides me and Annie?! :)
>>
>> Do you mean
>> "Bingo! When I set acceptRanges to false in webdefault.xml, the problem
>> goes away." ?
>>
>> The webdefaults.xml file is located at
>> [LENYA_HOME]/tools/jetty/conf/webdefaults.xml
>>
>> That thread talks about serving byte ranges. This is what the "fast web
>> view" option does, it uses byte range requests to download only parts
>> of
>> the PDF file.
>> So disabling this option in the reader should have the same effect as
>> disabling it in the server.
>>
>> If nothing else helps, you could try a different servlet container,
>> like
>> Tomcat, to see if it's a jetty problem.
>>
>> Josias
>
>
> Yup, that's what I was referring to. I actually made the change to our
> server and it doesn't seem to make a difference. But while I'd like to
> test with Tomcat, there's no way I'm switching back after the good luck
> I've been having with Jetty. :) Here's another document that has some
> discussion on the issue, but no real concrete answers for me, unless
> you see something useful:
> http://72.14.207.104/search?q=cache:JUZXj0O4yXAJ:www.newsarch.com/> archive/mailinglist/comp/java/jetty/general/
> msg00360.html+Jetty+IE+%22The+file+is+damaged+and+could+not+be+repaired.
> %22&hl=en&client=firefox-a. I'll see if the test instance of Tomcat
> serving the same PDF document solves the issue and post a response
> here.
>
> Jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
 RE: PDF problems in IE
>> Well I was able to do a quick test using a default setup of Tomcat and
>> the Acrobat plug-in loads the page just fine in IE/Win. So it's
>> definitely down to some setup in Jetty/Cocoon/Lenya that's causing the
>> problem. Gregor, how does one set these headers in the sitemap? And
>> do you mean the publication-sitemap.xmap in each pub or the overall
>> sitemap? Did you create a pipeline that made this work for all PDF
>> files?:
>>
>
> <map:pipeline type="noncaching">
> <map:parameter name="expires" value="access"/>
> <map:match pattern="**/*.pdf">
> ... stuff in here ...
> </map:match>
>
> should take care of the cache expiry headers
Well I added the following pipeline into my pub's sitemap file:
<map:pipeline type="noncaching">
<map:parameter name="expires" value="access"/>
<map:match pattern="**/*.pdf">
<map:read src="resources/authoring/{1}/{2}.pdf" mime-type="application/pdf"/>
</map:match>
</map:pipeline>
Then I go to Lenya, click on the link in IE/Win with Acrobat 7 combination and the file is working. Thank God, I think to myself. I finally solved the problem. So then I check out the live environment - same computer, same setup. "The file is corrupt or damaged and cannot be repaired." So what the heck? It doesn't make any sense - it seems to be completely random. I'm serving the same file on the same computer and same setup with the only difference is one is in the authoring environment and the other is in the live environment and the results are different. Then some files now work in the live environment and others do not.
Just as an example, go ahead and check out this page: http://alumni.hiram.edu/events/homecoming.html. Click on the big link using IE/Win with Acrobat Reader as plugin and see what you get. I continue to get file damaged errors, but some people say they can see it fine. It just seems so random. Anyone have any ideas? I'm feeling pretty helpless on this one...
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Linczak, Jonathan W. wrote:
> so random. Anyone have any ideas? I'm feeling pretty helpless on this
> one...
>
A couple of years ago, IE drove us nuts by ignoring the http headers
entirely and going only by the filename suffix. The file had to be
*.pdf or IE did unreasonable things. That wouldn't explain randomness,
though. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Linczak, Jonathan W. schrieb:
> (...)
> Then I go to Lenya, click on the link in IE/Win with Acrobat 7 combination and the file is working. Thank God, I think to myself. I finally solved the problem. So then I check out the live environment - same computer, same setup. "The file is corrupt or damaged and cannot be repaired." So what the heck? It doesn't make any sense - it seems to be completely random. I'm serving the same file on the same computer and same setup with the only difference is one is in the authoring environment and the other is in the live environment and the results are different. Then some files now work in the live environment and others do not.
>
> Just as an example, go ahead and check out this page: http://alumni.hiram.edu/events/homecoming.html. Click on the big link using IE/Win with Acrobat Reader as plugin and see what you get. I continue to get file damaged errors, but some people say they can see it fine. It just seems so random. Anyone have any ideas? I'm feeling pretty helpless on this one...
>
Jon, we had the same problem a couple of years ago, unfortunately I
can't find the solution from that time. It was Apache-based anyway, and
involved telling Apache to do a workaround in the http headers for this
IE+Adobe problem. I can't remember if the workaround involved changing
the expires header or not; whatever the workaround was, it no longer
seems necessary (we did a new system installation a few months ago) and
google can not find the pages I found on that subject back then :/
So I'm sorry I can't really help you, but what I would suggest you do:
- the apparent "randomness" in Web stuff usually comes from caching
problems. Whatever you may have set in the server, I suggest that before
any client test, you clear the browser's cache
- regarding differences in environments, be sure to know the whole chain
of software in both situations. Unfortunately, any piece of software
might change your http headers on the way; that includes things like
proxies and sometimes firewalls, too.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
On Sep 1, 2005, at 3:45 AM, J. Wolfgang Kaltz wrote:
> Linczak, Jonathan W. schrieb:
>> (...)
>> Then I go to Lenya, click on the link in IE/Win with Acrobat 7
>> combination and the file is working. Thank God, I think to myself.
>> I finally solved the problem. So then I check out the live
>> environment - same computer, same setup. "The file is corrupt or
>> damaged and cannot be repaired." So what the heck? It doesn't make
>> any sense - it seems to be completely random. I'm serving the same
>> file on the same computer and same setup with the only difference is
>> one is in the authoring environment and the other is in the live
>> environment and the results are different. Then some files now work
>> in the live environment and others do not.
>> Just as an example, go ahead and check out this page:
>> http://alumni.hiram.edu/events/homecoming.html. Click on the big link
>> using IE/Win with Acrobat Reader as plugin and see what you get. I
>> continue to get file damaged errors, but some people say they can see
>> it fine. It just seems so random. Anyone have any ideas? I'm
>> feeling pretty helpless on this one...
>
> Jon, we had the same problem a couple of years ago, unfortunately I
> can't find the solution from that time. It was Apache-based anyway,
> and involved telling Apache to do a workaround in the http headers for
> this IE+Adobe problem. I can't remember if the workaround involved
> changing the expires header or not; whatever the workaround was, it no
> longer seems necessary (we did a new system installation a few months
> ago) and google can not find the pages I found on that subject back
> then :/
>
> So I'm sorry I can't really help you, but what I would suggest you do:
>
> - the apparent "randomness" in Web stuff usually comes from caching
> problems. Whatever you may have set in the server, I suggest that
> before any client test, you clear the browser's cache
> - regarding differences in environments, be sure to know the whole
> chain of software in both situations. Unfortunately, any piece of
> software might change your http headers on the way; that includes
> things like proxies and sometimes firewalls, too.
I found this interesting thread that looked at using mod_proxy as being
the problem by not sending the content-length header. Here's the link:
http://www.issociate.de/board/post/4366/
pdf_with_byterange_doesn't_work,_or_why_content-
length_is_removed_by_mod_proxy.html
I did this as a test through mod_proxy and without and sure enough the
content-length is removed. Of course, the blame is on the IE browser
and their solution is to have IE forced to use HTTP/1.0. And of
course, that was 2 years ago - although I realize that IE hasn't
changed much in quite a long time. I added the following item into my
virtualhost configuration in Apache:
BrowserMatch "MSIE 6\.0;" nokeepalive downgrade-1.0 force-response-1.0
A quick test of this reveals that it does absolutely nothing to help
the situation. If the bug is display the content-length header, is
there a way to force this? Am I even going in the right direction of
finding out the problem? I know we're kinda trailing off the whole
Lenya thing, but if this is a common setup for people, surely others
are going to experience this, and it only happened after I moved to
Jetty built in to Lenya. If you guys were going to check this out,
what would be the first things you would do to figure out this problem?
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Jonathan Linczak schrieb:
> (...)
> A quick test of this reveals that it does absolutely nothing to help
> the situation. If the bug is display the content-length header, is
> there a way to force this? Am I even going in the right direction of
> finding out the problem?
I think so. IIRC my problems were regarding the content-length header as
well, and IE causing problems because it would only retrieve a chunk of
the PDF.
> I know we're kinda trailing off the whole
> Lenya thing, but if this is a common setup for people, surely others
> are going to experience this, and it only happened after I moved to
> Jetty built in to Lenya. If you guys were going to check this out,
> what would be the first things you would do to figure out this problem?
So it seems Jetty is sending a different response (in the headers) than
Tomcat did. I'd try to log these responses (try a debug setting for the
webservers) and see where the difference is. You might want to ask on
the Jetty mailing list as well.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
RE: PDF problems in IE
>> (...)
>> A quick test of this reveals that it does absolutely nothing to help
>> the situation. If the bug is display the content-length header, is
>> there a way to force this? Am I even going in the right direction of
>> finding out the problem?
>
> I think so. IIRC my problems were regarding the content-length header as
> well, and IE causing problems because it would only retrieve a chunk of
> the PDF.
>
>> I know we're kinda trailing off the whole
>> Lenya thing, but if this is a common setup for people, surely others
>> are going to experience this, and it only happened after I moved to
>> Jetty built in to Lenya. If you guys were going to check this out,
>> what would be the first things you would do to figure out this problem?
>
> So it seems Jetty is sending a different response (in the headers) than
> Tomcat did. I'd try to log these responses (try a debug setting for the
> webservers) and see where the difference is. You might want to ask on
> the Jetty mailing list as well.
Thanks Wolfgang - I did even more digging and testing, and I think I found a viable lead in finding out why this is happening. I used the "lynx -head -dump URL" command for both straight to Jetty and through my mod_proxy setup. Sure enough, the content-length header is removed when going through mod_proxy. So I did a search on mod_proxy removing the content-length header and I found this thread: http://www.issociate.de/board/post/4392/Apache_proxy_serving_M$-junk.html. Turns out that the problem was not fixed past the 2.0.46 version, which also happens to be the latest version that is on RedHat Linux Enterprise 3, the OS we have installed on the server. I think in a later, yet-unleased version 2.0.55 a fix to this problem is applied according to the truck CHANGES file, but that doesn't help the current situation.
I wish there were an easy answer to this one - we may have to serve all PDF files from the Apache document root without mod_proxy to have downloads that work in MSIE/Acrobat... unless of course someone else has some suggestions.
Thanks!
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
|
Re: PDF problems in IE
Linczak, Jonathan W. schrieb:
> (...) Sure enough, the content-length header is removed when going through mod_proxy. So I did a search on mod_proxy removing the content-length header and I found this thread: http://www.issociate.de/board/post/4392/Apache_proxy_serving_M$-junk.html. Turns out that the problem was not fixed past the 2.0.46 version, which also happens to be the latest version that is on RedHat Linux Enterprise 3, the OS we have installed on the server. I think in a later, yet-unleased version 2.0.55 a fix to this problem is applied according to the truck CHANGES file, but that doesn't help the current situation.
What about the mime-type, is it affected ?
IIRC one workaround was to set mime type for PDF to application/x-pdf
instead of application/pdf, because this is not a built-in mime-type in
MS-Internet Exploder, so IE doesn't try to do anything "smart" with it.
I remember this being a workaround to *one* IE+PDF problem, but not
whether it was regarding exactly *this* problem.
We currently have Apache 2.0.50 and no longer have that PDF problem. The
only configuration thing I can find relating to PDFs which is not
standard, is that I commented out the pdf line in /etc/apache2/magic -
but I can't remember why, sorry :/
>
> I wish there were an easy answer to this one - we may have to serve all PDF files from the Apache document root without mod_proxy to have downloads that work in MSIE/Acrobat... unless of course someone else has some suggestions.
I'd first install a more recent Apache to see what happens.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...
|
winmail.dat (4K) 