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.

Reply via email to