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]
