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