RE: Content_Length Problem
Just wanted to reply and let you guys know that enabling chunked encoding solved my connection issues with CICS. Thanks for all the help, I would have never found this solution without your assistance. Thanks- Joe -Original Message- From: Tim Whittington [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 4:36 PM To: 'Tomcat Users List' Subject: RE: Content_Length Problem That log statement indicates you haven't enabled chunked encoding in the connector config (it's off by default). Add enable_chunked_encoding=true to your isapi_redirect.properties (or as a registry setting if you're using that) and restart IIS. tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Wednesday, 9 January 2008 3:25 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem I have tried the isapi_redirect.dll Tim provided, and it appeared to almost work. CICS made the request and received my response but for some reason did not interpret it correctly. Is there something in the redirector's log that I can look at to verify it is using chunked encoding? I see the following line, but never see one where chunked encoding is true. [Tue Jan 08 08:05:07.220 2008] [13680:12960] [debug] init_jk::jk_isapi_plugin.c (2146): Using chunked encoding? false. Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Saturday, January 05, 2008 11:05 AM To: Tomcat Users List Subject: Re: Content_Length Problem In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics. ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/ com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Content_Length Problem
I have tried the isapi_redirect.dll Tim provided, and it appeared to almost work. CICS made the request and received my response but for some reason did not interpret it correctly. Is there something in the redirector's log that I can look at to verify it is using chunked encoding? I see the following line, but never see one where chunked encoding is true. [Tue Jan 08 08:05:07.220 2008] [13680:12960] [debug] init_jk::jk_isapi_plugin.c (2146): Using chunked encoding? false. Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Saturday, January 05, 2008 11:05 AM To: Tomcat Users List Subject: Re: Content_Length Problem In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics. ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/ com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Content_Length Problem
That log statement indicates you haven't enabled chunked encoding in the connector config (it's off by default). Add enable_chunked_encoding=true to your isapi_redirect.properties (or as a registry setting if you're using that) and restart IIS. tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Wednesday, 9 January 2008 3:25 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem I have tried the isapi_redirect.dll Tim provided, and it appeared to almost work. CICS made the request and received my response but for some reason did not interpret it correctly. Is there something in the redirector's log that I can look at to verify it is using chunked encoding? I see the following line, but never see one where chunked encoding is true. [Tue Jan 08 08:05:07.220 2008] [13680:12960] [debug] init_jk::jk_isapi_plugin.c (2146): Using chunked encoding? false. Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Saturday, January 05, 2008 11:05 AM To: Tomcat Users List Subject: Re: Content_Length Problem In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics. ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/ com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Content_Length Problem
From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces
Re: Content_Length Problem
Joe, Tim is right. It's not necessary a problem of the webapp. If content is dynamic and it doesn't make much sense to set content-length before the response, when using AJP it's the responsibility of the web server to handle the dynamic nature of the response. AJP itself knows how to signal the end of the response, and Apache httpd automatically converts such a dynamic reponse (better: one that didn't come from the backend with a content-length) into chunked encoding. Our IIS redirector instead closes the connection, which is another way of signaling the end of the response. It looks like the CICS people have to improve their HTTP implementation to support at least one of those two cases, and then you can choose the appropriate web server. Regards, Rainer Tim Whittington schrieb: From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file
RE: Content_Length Problem
Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm do you need IIS running..is there a way to perhaps use Apache with mod_jk just to ensure http-1.1 chunked encoding/content-length bilateral connections are supported? Then once all your staging environments are operational then sub in IIS with all those mysterious dlls? Martin __Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: RE: Content_Length Problem Date: Sat, 5 Jan 2008 22:41:31 +1300 From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length
Re: Content_Length Problem
In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Content_Length Problem
I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail.
Re: Content_Length Problem
Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL
RE: Content_Length Problem
Rainer, I don't think that chunked encoding will solve the problem I outlined. Just out of curiosity is there something special I need to do to enable chunked encoding once the patch is applied? Where is a good place to upload my log file? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 3:29 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, the isapi chunked encoding patch shouldn't solve your problem. As I understand the topic it will not add a content-length header but enable chunked encoding, which doesn't use content-length. Clean up your jk log and let us/me have a look at it. I hope we can then see if anything is wrong and if so what it is. Regards, Rainer Woytasik Joe schrieb: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS
Re: Content_Length Problem
Hi Joe, the isapi chunked encoding patch shouldn't solve your problem. As I understand the topic it will not add a content-length header but enable chunked encoding, which doesn't use content-length. Clean up your jk log and let us/me have a look at it. I hope we can then see if anything is wrong and if so what it is. Regards, Rainer Woytasik Joe schrieb: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can
RE: Content_Length Problem
Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional
Re: Content_Length Problem
If you can sniff the response headers, you should be able to see whether the Transfer-Encoding is chunked or not. -- Len On Jan 4, 2008 4:10 PM, Woytasik Joe [EMAIL PROTECTED] wrote: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient
Re: Content_Length Problem
There's no Content-Length coming from the backend. See below. So: are you sure the backend sends it, if you send the same request without a web server in front of Tomcat? I would expect, that it's also missing, if you contact Tomcat directly via httpd. In this case it's an error in the webapp. Woytasik Joe schrieb: Here is my log, let me know if you see anything. Sending the request to the backend... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): sending to ajp13 pos=4 len=501 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 12 34 01 F1 02 04 00 08 48 54 54 50 2F 31 2E 31 - .4..HTTP/1.1 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 001000 00 14 2F 62 63 2F 42 69 6C 6C 69 6E 67 43 65 - .../xx/ ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 01f036 38 36 00 FF 00 00 00 00 00 00 00 00 00 00 00 - 686. Since it's a POSt request, we also need to send the request body to the backend ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1261): request body to send 670 - request body to resend 0 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): sending to ajp13 pos=4 len=676 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 12 34 02 A0 02 9E 54 61 62 42 61 72 25 33 41 50 - .4TabBar%3AP ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 02a044 61 79 73 00 00 00 00 00 00 00 00 00 00 00 00 - Days The next log line tells us, that we already got an answer back: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=167 max=8192 Here comes the dump of the headers of the answers. If I decode the packet with the protocol specification, I get the same result, as what is printed out in clear text below: Packet dump: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 04 00 C8 00 02 4F 4B 00 00 05 00 0D 43 61 63 68 - .OK.Cach ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 00a03D 55 54 46 2D 38 00 00 00 00 00 00 00 00 00 00 - =UTF-8.. Clear text: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (602): status = 200 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (609): Number of headers is = 5 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[0] [Cache-Control] = [no-cache] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[1] [Set-Cookie] = [rcou=87] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[2] [Pragma] = [no-cache] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[3] [Expires] = [Thu, 01 Jan 1970 00:00:00 GMT] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[4] [Content-Type] = [text/html;charset=UTF-8] And now we get the response body. Content-Length would have come before, but the response from the backend isn't chunked either. For an answer including Content-Length see below. [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=8188 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 03 1F F8 3C 68 74 6D 6C 3E 0D 0A 3C 68 65 61 64 - ...html..head ... Now the next request is for a JavaScript file, and that request gets a response (404 error page), which includes a Content-Length: [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_isapi_plugin.c (852): Virtual Host redirection of /xx.xxX.com/xx/resources/javascript/smoketest/SmokeTest.js ... [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=120 max=8192 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): 04 01 94 00 2F 2F 62 63 2F 72 65 73 6F 75 72 63 - //xx/resourc ... [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): 007000 00 04 31 30 39 33 00 00 00 00 00 00 00 00 00 - ...1093. [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (602): status = 404 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (609): Number of headers is = 2 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (665): Header[0] [Content-Type] = [text/html;charset=utf-8] This is fine and is missing for the first request. [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (665): Header[1] [Content-Length] = [1093] [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=1097 max=8192 Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To
