Hello, meanwhile I traced also the HTTP traffic between browser and cocoon and recognized that surprisingly - at least for me - even there the HTTP GET request was sent twice. So, it must be an IE problem.
Regards, Elmar -----Ursprüngliche Nachricht----- Von: Sternath Elmar [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 17. Februar 2003 14:27 An: '[EMAIL PROTECTED]' Betreff: AW: strange behaviour of ResourceReader Hello, I have some additional information concerning my ResourceReader problem. I found that the ResourceReader sends its HTTP GET twice (as already described) because the URL defined in the sitemap is called twice: DEBUG (2003-02-17) 10:29.44:357 [sitemap] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-13/sitemap_xmap: Matched wildcard pattern scworkflow/** DEBUG (2003-02-17) 10:29.44:357 [sitemap] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-13/AbstractSitemap: Current Sitemap Parameters: PARAM: '1' VALUE: 'DownloadDocumentById/DocumentView' PARAM: '0' VALUE: 'scworkflow/DownloadDocumentById/DocumentView' DEBUG (2003-02-17) 10:29.44:377 [sitemap.action.request-encoded] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-13/RequestEncodedParamAction: Encode Parameter: DocFormat with value: application/pdf DEBUG (2003-02-17) 10:29.44:377 [sitemap.action.request-encoded] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-13/RequestEncodedParamAction: Encode Parameter: DocId with value: 7 0x012d5c83@NETINFO DEBUG (2003-02-17) 10:29.48:473 [sitemap] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-40/sitemap_xmap: Matched wildcard pattern scworkflow/** DEBUG (2003-02-17) 10:29.48:473 [sitemap] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-40/AbstractSitemap: Current Sitemap Parameters: PARAM: '1' VALUE: 'DownloadDocumentById/DocumentView' PARAM: '0' VALUE: 'scworkflow/DownloadDocumentById/DocumentView' DEBUG (2003-02-17) 10:29.48:483 [sitemap.action.request-encoded] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-40/RequestEncodedParamAction: Encode Parameter: DocFormat with value: application/pdf DEBUG (2003-02-17) 10:29.48:483 [sitemap.action.request-encoded] (/cocoon/scworkflow/DownloadDocumentById/DocumentView) Thread-40/RequestEncodedParamAction: Encode Parameter: DocId with value: 7 0x012d5c83@NETINFO Between these two calls, no user interaction at the browser took place. So it looks more like a problem of the Cocoon framework, but only with IE, not with Netscape. Any suggestions/comments are continuously appreciated. Best regards, Elmar -----Ursprüngliche Nachricht----- Von: Sternath Elmar [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 14. Februar 2003 11:40 An: '[EMAIL PROTECTED]' Betreff: strange behaviour of ResourceReader Hello, I use cocoon 2.0.4 on tomcat 4.1.12 and recognize an extremely strange behaviour of ResourceReader: The problem occurs only in IE (5.5), not at all in Netscape (7). The problem occurs only with pdf files. The browser behaviours differ in that way that IE tries to open AcrobatReader inside, where Netscape opens an extra window. I try to get a pdf using ResourceReader by HTTP POST in .xsl: <map:when test="application/pdf"> <map:read mime-type="application/pdf" src="http://{../1}:{1}@localhost:8889/BOLServlet/DocumentService.downloadDocumentById/Pruefungsbericht.pdf"/> </map:when> Now I get an exception in access.log: org.apache.cocoon.ConnectionResetException: Connection reset by peer: java.net.SocketException: Connection reset by peer: socket write error at org.apache.cocoon.components.pipeline.CachingStreamPipeline.processReader(CachingStreamPipeline.java:260) at org.apache.cocoon.components.pipeline.AbstractStreamPipeline.process(AbstractStreamPipeline.java:168) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:289) at org.apache.cocoon.www.file_.Z_.scw.sitemap_xmap.matchN104E4(C:\Programme\Apache-Tomcat-4.1.12\work\Standalone\localhost\cocoon\cocoon-files\org/apache/cocoon/www/file_/Z_/scw\sitemap_xmap.java:3986) at org.apache.cocoon.www.file_.Z_.scw.sitemap_xmap.process(C:\Programme\Apache-Tomcat-4.1.12\work\Standalone\localhost\cocoon\cocoon-files\org/apache/cocoon/www/file_/Z_/scw\sitemap_xmap.java:1154) at org.apache.cocoon.www.file_.Z_.scw.sitemap_xmap.process(C:\Programme\Apache-Tomcat-4.1.12\work\Standalone\localhost\cocoon\cocoon-files\org/apache/cocoon/www/file_/Z_/scw\sitemap_xmap.java:974) Next, I try to get the same pdf using an HTTP GET in .xsl. Now, the file is displayed correctly inside IE and no exception occured any more in access.log. I traced the HTTP connection to the target PDF and recognized that the file was transferred twice using HTTP GET, but only once using HTTP POST. Beside that, all three responses are absolutely identical. And now, the surprise becomes perfect: If I use again HTTP POST, it works also!! From now on, both with HTTP POST and GET calls in .xsl the file is transferred only once. When I delete tomcat's work dir and restart tomcat, the same story rehappens. Any ideas?? (Should be a challenge for Carsten!) Mit freundlichen Grüßen/ Best regards Elmar Sternath Siemens AG Information and Communication Networks ICN IT CA EB 2 - Web Applications Mch H/Me19 - 99801-231a Meglinger Straße 19 (99801-231a) D-84577 München Tel.: +49(89)722-24045 Mobil: +49(0)160-5860351 Fax.: +49(89)722-53384 EMail: [EMAIL PROTECTED] <<Sternath Elmar.vcf>> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
