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, > 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]
